OSDev.org

bwat wrote:

BMW wrote:

bwat wrote:If you're on linux, type "man end" or go here http://man7.org/linux/man-pages/man3/end.3.html and see how the symbols are used.
You don't have to shift stuff around, you'll only have to clear the BSS section. Unless of course you're doing something I'm not - I just keep it simple.

Hold on, is the .bss present in a flat binary but not initialised? So all I have to do is zero it?

I have a program that copies the ELF TEXT & DATA segments to an image file which my bootstrap loader reads from disk. I don't create the BSS part of the image so I have to clear it in memory after it has loaded. I could generate a block of zeroes in the image for the BSS if I wanted to but that would increase the size of the image.

By zeroing the BSS section after the OS has loaded, you'll have a method that works regardless of the format of the OS executable that is loaded.

BMW wrote: So where would you zero the BSS? I have a "loader" which is written is assembly and simply calls kmain(). Would I zero the BSS in that loader, before I jump to the kernel?

bwat wrote:

BMW wrote: So where would you zero the BSS? I have a "loader" which is written is assembly and simply calls kmain(). Would I zero the BSS in that loader, before I jump to the kernel?

Anything that is linked with the OS will have "end" and "edata" within scope. It is my OS that initialises its own BSS. I initialise my BSS, then I initialise my OS C stack, then I call my OS main C function. That's why the code I showed was in assembly and not C --- my bzero is an assembly routine as well. So, if I were in your shoes, I would get your loader to call your kernel's init routine which zeroed the BSS before calling your kmain. This is, of course, not the only way to do it.

.bss ALIGN (0x1000) :
{
        sbss = .;
        *(COMMON)
        *(.bss)
        ebss = .;
}

extern kmain
extern sbss
extern ebss
loader:
	;zero bss
	mov ebx, sbss
zloop:
	mov [ebx], byte 0
	inc ebx
	cmp ebx, ebss
	jb zloop

	jmp kmain

bwat wrote:I initialise my BSS, then I initialise my OS C stack

Combuster wrote:

bwat wrote:I initialise my BSS, then I initialise my OS C stack

And your code says you're using the stack before initializing it.

Combuster wrote:You can have the linker emit flat binaries with .bss preallocated and without .bss depending on the linker script you're using. The linker script is also the place that inserts special symbols on section boundaries. If you try the same route with objcopy, you get similar results. In other words, you can choose to include the .bss as .data

BMW wrote:

Combuster wrote:You can have the linker emit flat binaries with .bss preallocated and without .bss depending on the linker script you're using. The linker script is also the place that inserts special symbols on section boundaries. If you try the same route with objcopy, you get similar results. In other words, you can choose to include the .bss as .data

If you put the .bss section in the linker script, will this make it preallocated in the binary?

Or do you mean you put the *(.bss) in the .data section so it includes it as data?

Combuster wrote:Pretty much. My test case essentially consisted of the following constructs (using the host compiler) for elf and binary targets.

Code: Select all

/* embeds bss in file */
.data : { 
    *(.data*)
    *(COMMON)
    *(.bss*)
}

Code: Select all

/* does not actually store the NULL bytes for bss */
.data : {
    *(.data*)
}
.bss : {
    *(COMMON)
    *(.bss*)
}

Combuster wrote:Pretty much. My test case essentially consisted of the following constructs (using the host compiler) for elf and binary targets.

Code: Select all

/* embeds bss in file */
.data :
{ 
    *(.data*)
    *(COMMON)
    *(.bss*)
}

Code: Select all

/* does not actually store the NULL bytes for bss */
.data :
{
    *(.data*)
}
.bss :
{
    *(COMMON)
    *(.bss*)
}