mid wrote:
I'm still expecting a yes/no answer to my quesion.
mid wrote:
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.
mid wrote:
will ld zero-initialize the range of memory that corresponds to the input .bss section
No.
mid wrote:
or should I assume it to be link-time garbage?
No. It's going to be run-time garbage.
mid wrote:
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.
mid wrote:
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:
uint64_t example_uninitialized_variable;
Then in the program headers your only segment will have
memsz ==
filesz + 8.
Cheers,
bzt