[PATCH] D150510: [ELF] x86-64: place .lrodata, .lbss, and .ldata away from code sections

[James Y Knight via Phabricator via llvm-commits]

jyknight added a comment.

>>> Splits segments at NOBITS->BITS boundaries, so that a new segment is started between .bss and .ldata (assuming there is .bss).
>>
>> why is this necessary?
>
> As I noted in the description:
>
>> While GNU ld places .lbss after .bss, the subsequent sections don't reuse the file offset bytes of BSS. We have a similar missing optimization (implementing it would introduce complexity and likely be error-prone).
>
> If we start a new PT_LOAD at NOBITS->BITS boundaries, we can in theory implement such a file size optimization.
> `fixSectionAlignments` and `assignFileOffsets` would need some involved code.
> I think this is error-prone and may not be a worthwhile change.

As a reminder, the section layout we're talking about is: `.data` (PROGBITS RW), `.bss` (NOBITS RW), `.ldata` (PROGBITS RW LARGE). The question is whether to cover all three sections with a single LOAD, or whether to use two LOADs, one for `.data` and `.bss`, and the second for `.ldata`.

In the former case, you cannot use the ability of an ELF LOAD to specify a smaller filesize than memory memory-size -- where the remainder of the memory-size gets zero-filled by the loader, because that can only be at the end of the LOAD. Thus, in that model, if you have 8MB of `.bss`, you will waste 8MB of zeros in the binary.

My patch does the latter, instead, and that saves space, already, without additional changes to other functions. Because of the way the alignment code works, you'll still waste some bytes in the file, but only up to max-page-size bytes (which defaults to 4K for x86-64; users can change it with `-z,max-page-size=` if they like).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150510/new/

https://reviews.llvm.org/D150510