Hello,
Could someone explain why the .bss section is being combined with the
.data section in the GCC linker script in the EDK2? This will force all
uninitialized variables to take space in the output .efi file. This
seems really wasteful.
GccBase.lds
/*
* The alignment of the .data section should be less than or equal to
* the alignment of the .text section. This ensures that the relative
* offset between these sections is the same in the ELF and the PE/COFF
* versions of this binary.
*/
.data ALIGN(ALIGNOF(.text)) : ALIGN(CONSTANT(COMMONPAGESIZE)) {
*(.data .data.* .gnu.linkonce.d.*)
*(.bss .bss.*)
}
At first I thought that the PE COFF file format couldn't support an
uninitialized data section, but this isn't the case. Then, I thought
the UEFI designers just overlooked the issue. However, I noticed that
the LoadImage() code in BasePeCoff.c will ZERO out the remaining data in
a section if its raw size is less than its virtual size.
//
// If raw size is less then virt size, zero fill the remaining
//
if (Size < Section->Misc.VirtualSize) {
ZeroMem (Base + Size, Section->Misc.VirtualSize - Size);
}
If it is true that the UEFI LoadImage() routine will zero the end of a
section, then the GenFw executable could create a .bss section with a
raw size of 4 and a virtual size the equals the true size of the bss.
Another option is that GenFw could merge the .bss section to the end of
the .data section. Again, the raw size could equal the .data section
size and the virtual size could equal the size of both .data and .bss
sections combined.
I wonder how much space could be saved if the UEFI executables had a
.bss section?
Thanks,
Stephen
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
