.bss -> .text in linker script. Will it be zero-initialized?

[mid]

Ignoring the size inflation from doing such a thing in the first place, will ld zero-initialize the range of memory that corresponds to the input .bss section, or should I assume it to be link-time garbage? Is there a way to force ld to zero-initialize this memory?

Code: Select all

OUTPUT_FORMAT("elf32-i386")
OUTPUT_ARCH(i386)

ENTRY(kmain)

SECTIONS
{
	. = 0;
	.text : {
		*(.text)
		*(.data)
		*(.bss)
		*(.rodata*)
	}
	_kernel_end = .;
}

[antoni]

will ld zero-initialize the range of memory that corresponds to the input .bss section, or should I assume it to be link-time garbage?

BSS means uninitialised memory. LD won't initialize it, and it don't have to, the loader is responsible for that. Initializing it with zeros would be a horrific waste of storage. You should assume that any object in this section is zeroed. Some operating systems fill it with zero it at load time. Some systems clear this memory at first read as an optimalisation.

If we are talking about kernel, however, it will obviously be loaded by the bootloader into free memory, which is zeroed. This means that ALL of your variables (even local) will be set to zero. Obviously, bss section is zeroed out too.

[mid]

The point is that my bootloader doesn't have any knowledge of particular sections; it doesn't know what to zero-initialize, because it's all put into one section.

[MichaelFarthing]

The point is that my bootloader doesn't have any knowledge of particular sections; it doesn't know what to zero-initialize, because it's all put into one section.

I zero my OS memory. Doesn't take long and gives me a sense of security. It also means that during development (which I do from inside the OS itself) then unless I have a disastrous crash I can safely fast reboot a new version without having to clear up any mess first.

[mid]

The point is that my bootloader doesn't have any knowledge of particular sections; it doesn't know what to zero-initialize, because it's all put into one section.

I zero my OS memory. Doesn't take long and gives me a sense of security. It also means that during development (which I do from inside the OS itself) then unless I have a disastrous crash I can safely fast reboot a new version without having to clear up any mess first.

That's great.

I'm still expecting a yes/no answer to my quesion.

[bzt]

I'm still expecting a yes/no answer to my quesion.

Ignoring the size inflation from doing such a thing in the first place

No. The .bss section does not influence the executable size in any way.

will ld zero-initialize the range of memory that corresponds to the input .bss section

No.

or should I assume it to be link-time garbage?

No. It's going to be run-time garbage.

Is there a way to force ld to zero-initialize this memory?

As others have already said, it is the loader's duty, or you should write ALL programs specifically either not to care about the garbage or zero out before use. Implementing it in the loader is a better approach.

The point is that my bootloader doesn't have any knowledge of particular sections; it doesn't know what to zero-initialize, because it's all put into one section.

It doesn't have to. According to your linker script, you're going to have a single segment which your loader must load. It's going to have filesz bytes in the file, and the difference to memsz should be zerod out (that's where the .bss resides).

If your code doesn't have uninitialized values, then memsz == filesz. If you have this for example (outside of functions):

Code: Select all

uint64_t example_uninitialized_variable;

Then in the program headers your only segment will have memsz == filesz + 8.

Cheers,
bzt

[Octocontrabass]

If you force LD to initialize the contents of the .bss section, it will be filled with zeroes.

I'm not sure why you would want LD to do this instead of your bootloader.