[lld] Fix .bss section accumulated in ELF file (PR #78265)

Peter Smith via llvm-commits llvm-commits at lists.llvm.org
Tue Jan 16 07:03:30 PST 2024


smithp35 wrote:

Thanks for the patch. I think we'll need to have a discussion on what we want the behaviour of LLD to be before evaluating a potential fix, I think we'll also want some new test cases that describe that behaviour. 

For example in a single PT_LOAD region if .bss precedes non .bss then if the size of the .bss is not added to the file-offset then the .bss when created may (when the .bss VMA and LMA are the same) overwrite the contents of the following non .bss section, however if the size is added then creating the .bss can be done.
```
    .data VMA 0x1000 LMA 0x1000 Size 4
    .bss VMA 0x1004 LMA 0x1004 Size 4
    /* .bss when created will overwrite following section if we don't increase file offset (LMA here) */
    /* If VMA was something different say 0x1000000 then LMA 0x1004 is fine */
    .more_data VMA 0x1008 LMA 0x1004 Size 4 
```
In summary if all the VMAs in a PT_LOAD are monotonically ascending and the sections are contiguous in VMA and VMA == LMA then it is probably better to reserve space for .bss.

I'm also a bit concerned that subtracting the .bss size seen so far from (os->addr - first->addr) might cause problems with alignment (in the file). For example:
```
    .data VMA 0x1000 size 4
    .bss VMA 0x1004 size 4
    .other VMA 0x1010 (align 0x10) size 4
```
If we just subtract 4 then we'll have altered the file offset alignment.

I do agree that there are problems lurking in computeFileOffsets though. In particular I think that MEMORY and PHDRS lets  people create non-monotonically ascending VMA in a PT_LOAD program header which I don't think computeFileOffsets works well for. I've seen a couple of issues filed for that.

I'm planning to do some investigations into how GNU ld and LLD handle address assignment over the next few weeks for a FOSDEM presentation in February. Will hopefully know the bounds of what works and what doesn't by then.



https://github.com/llvm/llvm-project/pull/78265


More information about the llvm-commits mailing list