Question: How .bss is loaded?

[BMW]

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.

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]

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.

[BMW]

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.

Yep I've just done it. Seems to work.

I declared sbss and ebss like this:

Code: Select all

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

Then zero like this:

Code: Select all

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

[Combuster]

I initialise my BSS, then I initialise my OS C stack

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

[bwat]

I initialise my BSS, then I initialise my OS C stack

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

No, the code you imagine says I'm using the OS C stack before initialising it!

The BSS and the OS C stack are initialised using the legacy bootloader stack. The bootloader may be used to load many different OSs with different stack requirements. Hence, the need for a stack switch.

[neurocom]

Thanks for the posts, but unfortunately, it's not clear to me and a bit confused.

I should ask step by step.

Assuming that a raw binary converted from ELF, Is the raw binary has any information about .bss?? If so, where and how?
I believe .bss is not present in a raw binary and that's why I started a question in this thread.

Can someone give me a clear answer?

Thanks

[Combuster]

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

The linker script is also the part that generates symbols on section boundaries. If you write your own, you'll have to explicitly create each of these symbols explicitly. Symbols get linked like any other variable, so after converting to a flat binary you can still tell where the section is, or was intended to be, and zero it manually if necessary.

[neurocom]

Thanks for the clear answer.

Next questoin is.
To include .bss section I added the below in my linker script, but it doesn't change any bit in the biinary. Am I missing something?
.bss :
{
*(.bss)
}

Also, Is it a common practice to include .bss section in a raw binary of kernel? (Someone may argue that the file size can be too big if we include .bss section)

Thank you

[BMW]

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?

[neurocom]

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?

I'm sure if you specify .bss section seperate from other sections, it does NOT inlcude anything

[Combuster]

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*)
}

[neurocom]

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*)
}

Thanks, Combuster
I think everything is clear to me now.

[BMW]

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*)
}

Thanks, very helpful. I will test it myself, since knowledge is better than belief.