[llvm-dev] lld extra program headers
Rafael Avila de Espindola via llvm-dev
llvm-dev at lists.llvm.org
Thu Jun 29 17:34:30 PDT 2017
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
More information about the llvm-dev
mailing list