Hello all, The lld linker appears to generate extra ELF program headers and thus causes file sizes to be significantly larger than what would get with ld.gold or ld.bfd. # readelf -l test.bfd Elf file type is EXEC (Executable file) Entry point 0x4000b0 There are 2 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 0x00000000000000c0 0x00000000000000c0 R E 0x200000 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 0x10 Section to Segment mapping: Segment Sections... 00 .text 01 # readelf -l test.gold Elf file type is EXEC (Executable file) Entry point 0x4000b0 There are 2 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 0x00000000000000c0 0x00000000000000c0 R E 0x1000 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 0x10 Section to Segment mapping: Segment Sections... 00 .text 01 # readelf -l test.lld Elf file type is EXEC (Executable file) Entry point 0x201000 There are 4 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0x0000000000200040 0x0000000000200040 0x00000000000000e0 0x00000000000000e0 R 0x8 LOAD 0x0000000000000000 0x0000000000200000 0x0000000000200000 0x0000000000000120 0x0000000000000120 R 0x1000 LOAD 0x0000000000001000 0x0000000000201000 0x0000000000201000 0x0000000000000010 0x0000000000000010 R E 0x1000 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 0x0 Section to Segment mapping: Segment Sections... 00 01 02 .text 03 Now obviously disk space is relatively cheap these days but if it could be avoided, can we avoid generating these unused memory mappings unless a PT_INTERP section is going to be generated? I could also be misunderstanding things, and it might be normal to map the program's program headers into memory (and thus the entire ELF header). Thanks.
Hi Will, ld.gold and ld.bfd seem handle PHDR and INTERP as executable segments. That's why they use only one page for PHDR, INTERP and the first executable page. lld on the other hand handles them as non-executable segments, as they are not really executable code. I think what lld does is more desirable. On Thu, Jun 22, 2017 at 2:01 PM, Will Song via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hello all, > > The lld linker appears to generate extra ELF program headers and thus > causes file sizes to be significantly larger than what would get with > ld.gold or ld.bfd. > > # readelf -l test.bfd > > Elf file type is EXEC (Executable file) > Entry point 0x4000b0 > There are 2 program headers, starting at offset 64 > > Program Headers: > Type Offset VirtAddr PhysAddr > FileSiz MemSiz Flags Align > LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 > 0x00000000000000c0 0x00000000000000c0 R E 0x200000 > GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 > 0x0000000000000000 0x0000000000000000 RW 0x10 > > Section to Segment mapping: > Segment Sections... > 00 .text > 01 > # readelf -l test.gold > > Elf file type is EXEC (Executable file) > Entry point 0x4000b0 > There are 2 program headers, starting at offset 64 > > Program Headers: > Type Offset VirtAddr PhysAddr > FileSiz MemSiz Flags Align > LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 > 0x00000000000000c0 0x00000000000000c0 R E 0x1000 > GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 > 0x0000000000000000 0x0000000000000000 RW 0x10 > > Section to Segment mapping: > Segment Sections... > 00 .text > 01 > # readelf -l test.lld > > Elf file type is EXEC (Executable file) > Entry point 0x201000 > There are 4 program headers, starting at offset 64 > > Program Headers: > Type Offset VirtAddr PhysAddr > FileSiz MemSiz Flags Align > PHDR 0x0000000000000040 0x0000000000200040 0x0000000000200040 > 0x00000000000000e0 0x00000000000000e0 R 0x8 > LOAD 0x0000000000000000 0x0000000000200000 0x0000000000200000 > 0x0000000000000120 0x0000000000000120 R 0x1000 > LOAD 0x0000000000001000 0x0000000000201000 0x0000000000201000 > 0x0000000000000010 0x0000000000000010 R E 0x1000 > GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 > 0x0000000000000000 0x0000000000000000 RW 0x0 > > Section to Segment mapping: > Segment Sections... > 00 > 01 > 02 .text > 03 > > Now obviously disk space is relatively cheap these days but if it could > be avoided, can we avoid generating these unused memory mappings unless > a PT_INTERP section is going to be generated? I could also be > misunderstanding things, and it might be normal to map the program's > program headers into memory (and thus the entire ELF header). > > Thanks. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170622/b7377585/attachment-0001.html>
Rafael Avila de Espindola via llvm-dev
2017-Jun-30 00:34 UTC
[llvm-dev] lld extra program headers
Note too that that is just a different default. You can pass --no-rosegment to lld if you want. Cheers, Rafael Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> writes:> Hi Will, > > ld.gold and ld.bfd seem handle PHDR and INTERP as executable segments. > That's why they use only one page for PHDR, INTERP and the first executable > page. > > lld on the other hand handles them as non-executable segments, as they are > not really executable code. I think what lld does is more desirable. > > On Thu, Jun 22, 2017 at 2:01 PM, Will Song via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hello all, >> >> The lld linker appears to generate extra ELF program headers and thus >> causes file sizes to be significantly larger than what would get with >> ld.gold or ld.bfd. >> >> # readelf -l test.bfd >> >> Elf file type is EXEC (Executable file) >> Entry point 0x4000b0 >> There are 2 program headers, starting at offset 64 >> >> Program Headers: >> Type Offset VirtAddr PhysAddr >> FileSiz MemSiz Flags Align >> LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 >> 0x00000000000000c0 0x00000000000000c0 R E 0x200000 >> GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 >> 0x0000000000000000 0x0000000000000000 RW 0x10 >> >> Section to Segment mapping: >> Segment Sections... >> 00 .text >> 01 >> # readelf -l test.gold >> >> Elf file type is EXEC (Executable file) >> Entry point 0x4000b0 >> There are 2 program headers, starting at offset 64 >> >> Program Headers: >> Type Offset VirtAddr PhysAddr >> FileSiz MemSiz Flags Align >> LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 >> 0x00000000000000c0 0x00000000000000c0 R E 0x1000 >> GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 >> 0x0000000000000000 0x0000000000000000 RW 0x10 >> >> Section to Segment mapping: >> Segment Sections... >> 00 .text >> 01 >> # readelf -l test.lld >> >> Elf file type is EXEC (Executable file) >> Entry point 0x201000 >> There are 4 program headers, starting at offset 64 >> >> Program Headers: >> Type Offset VirtAddr PhysAddr >> FileSiz MemSiz Flags Align >> PHDR 0x0000000000000040 0x0000000000200040 0x0000000000200040 >> 0x00000000000000e0 0x00000000000000e0 R 0x8 >> LOAD 0x0000000000000000 0x0000000000200000 0x0000000000200000 >> 0x0000000000000120 0x0000000000000120 R 0x1000 >> LOAD 0x0000000000001000 0x0000000000201000 0x0000000000201000 >> 0x0000000000000010 0x0000000000000010 R E 0x1000 >> GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 >> 0x0000000000000000 0x0000000000000000 RW 0x0 >> >> Section to Segment mapping: >> Segment Sections... >> 00 >> 01 >> 02 .text >> 03 >> >> Now obviously disk space is relatively cheap these days but if it could >> be avoided, can we avoid generating these unused memory mappings unless >> a PT_INTERP section is going to be generated? I could also be >> misunderstanding things, and it might be normal to map the program's >> program headers into memory (and thus the entire ELF header). >> >> Thanks. >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev