vit9696 via llvm-dev
2017-Oct-09 17:54 UTC
[llvm-dev] Understanding of ldd header allocation
Hello,
I am currently switching to ldd from ld.bfd on a cross-platform embedded project
and am facing a behaviour difference when using the same linker scripts with
ld.bfd and ldd. Could anybody please give me a more reliable direction I should
go with to get the same behaviour from both of the linkers?
Target binary format is a 32-bit ELF executable, which is expected to consist of
a single RWX segment starting from base 0x80000000. (Since I can reproduce the
difference with at least mips, ppc32, x86, I attached the x86 linker script to
the message as an example.) What is expected from the resulting binary (and what
ld.bfd produces) is that no ELF headers are allocated in the address space, e.g.
Elf file type is EXEC (Executable file)
Entry point 0x80001a0f
There are 1 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x001000 0x80000000 0x80000000 0x08284 0x08284 RWE 0x1000
Section to Segment mapping:
Segment Sections...
00 .text .rodata .eh_frame .data
However, what ldd does is different. (To create a single segment I use --omagic
argument, it works fine and is unrelated). The first segment is created at a
lower address, with ELF headers in it, and then the actual text section exactly
at 0x80000000:
Elf file type is EXEC (Executable file)
Entry point 0x80002670
There are 3 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x7ffff034 0x7ffff034 0x00060 0x00060 R 0x4
LOAD 0x000000 0x7ffff000 0x7ffff000 0x0a098 0x0a098 RWE 0x1000
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x0
Section to Segment mapping:
Segment Sections...
00
01 .text .rodata .data
02
From what I understand if a linker script is used and the headers fail to
allocate, then they should not be present in the resulting binary. However, it
seems like ldd treats custom headers and automatically generated headers
differently (well, that's at least how I see it at the moment). I think, if
the headers are custom, they may not appear in the address space, otherwise they
(always?) do. I came up with this conclusion because adding the following
command appears to produce a correct binary:
PHDRS
{
main PT_LOAD;
}
Elf file type is EXEC (Executable file)
Entry point 0x80002670
There are 1 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x001000 0x80000000 0x80000000 0x09098 0x09098 RWE 0x1000
Section to Segment mapping:
Segment Sections...
00 .text .rodata .data
However, this is not valid for at least ld.bfd, which produces an error in this
case:
ld: no sections assigned to phdrs
At this step I feel a little confused, because even though I have a workaround,
it is unclear whether both behaviours (with and without the mentioned
workaround) are expected in the first place? Or might it actually be a bug in
either of the linkers? Ideally I have some workaround that works in both of the
linkers, but if it is not possible, I could continue going with PHDRS hack.
Best regards,
Vit
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example.lds
Type: application/octet-stream
Size: 293 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171009/ab39f667/attachment.obj>
-------------- next part --------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171009/ab39f667/attachment.sig>
Nemanja Ivanovic via llvm-dev
2017-Oct-09 21:59 UTC
[llvm-dev] Understanding of ldd header allocation
It sounds like your question is actually about LLD rather than LDD. I don't know anything about either, but I believe Rui Ueyama is the maintainer for LLD in case that's what your question is about. Of course, if your question is indeed about LDD, please ignore this and I unfortunately can't suggest someone that can help. On Mon, Oct 9, 2017 at 7:54 PM, vit9696 via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hello, > > I am currently switching to ldd from ld.bfd on a cross-platform embedded > project and am facing a behaviour difference when using the same linker > scripts with ld.bfd and ldd. Could anybody please give me a more reliable > direction I should go with to get the same behaviour from both of the > linkers? > > Target binary format is a 32-bit ELF executable, which is expected to > consist of a single RWX segment starting from base 0x80000000. (Since I can > reproduce the difference with at least mips, ppc32, x86, I attached the x86 > linker script to the message as an example.) What is expected from the > resulting binary (and what ld.bfd produces) is that no ELF headers are > allocated in the address space, e.g. > > > Elf file type is EXEC (Executable file) > Entry point 0x80001a0f > There are 1 program headers, starting at offset 52 > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > LOAD 0x001000 0x80000000 0x80000000 0x08284 0x08284 RWE 0x1000 > > Section to Segment mapping: > Segment Sections... > 00 .text .rodata .eh_frame .data > > > However, what ldd does is different. (To create a single segment I use > --omagic argument, it works fine and is unrelated). The first segment is > created at a lower address, with ELF headers in it, and then the actual > text section exactly at 0x80000000: > > > Elf file type is EXEC (Executable file) > Entry point 0x80002670 > There are 3 program headers, starting at offset 52 > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > PHDR 0x000034 0x7ffff034 0x7ffff034 0x00060 0x00060 R 0x4 > LOAD 0x000000 0x7ffff000 0x7ffff000 0x0a098 0x0a098 RWE 0x1000 > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x0 > > Section to Segment mapping: > Segment Sections... > 00 > 01 .text .rodata .data > 02 > > > From what I understand if a linker script is used and the headers fail to > allocate, then they should not be present in the resulting binary. However, > it seems like ldd treats custom headers and automatically generated headers > differently (well, that's at least how I see it at the moment). I think, if > the headers are custom, they may not appear in the address space, otherwise > they (always?) do. I came up with this conclusion because adding the > following command appears to produce a correct binary: > > PHDRS > { > main PT_LOAD; > } > > > Elf file type is EXEC (Executable file) > Entry point 0x80002670 > There are 1 program headers, starting at offset 52 > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > LOAD 0x001000 0x80000000 0x80000000 0x09098 0x09098 RWE 0x1000 > > Section to Segment mapping: > Segment Sections... > 00 .text .rodata .data > > > However, this is not valid for at least ld.bfd, which produces an error in > this case: > ld: no sections assigned to phdrs > > At this step I feel a little confused, because even though I have a > workaround, it is unclear whether both behaviours (with and without the > mentioned workaround) are expected in the first place? Or might it actually > be a bug in either of the linkers? Ideally I have some workaround that > works in both of the linkers, but if it is not possible, I could continue > going with PHDRS hack. > > Best regards, > Vit > > > > > > _______________________________________________ > 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/20171009/fdb99cb9/attachment.html>
vit9696 via llvm-dev
2017-Oct-09 22:05 UTC
[llvm-dev] Understanding of ldd header allocation
Oops, you are right of course. It is about lld, and I don't know what I was thinking about when repeating the same mistake over and over. I won't change the subject of the message for consistency though.> 10 окт. 2017 г., в 0:59, Nemanja Ivanovic <nemanja.i.ibm at gmail.com> написал(а): > > It sounds like your question is actually about LLD rather than LDD. I don't know anything about either, but I believe Rui Ueyama is the maintainer for LLD in case that's what your question is about. > > Of course, if your question is indeed about LDD, please ignore this and I unfortunately can't suggest someone that can help. > >> On Mon, Oct 9, 2017 at 7:54 PM, vit9696 via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Hello, >> >> I am currently switching to ldd from ld.bfd on a cross-platform embedded project and am facing a behaviour difference when using the same linker scripts with ld.bfd and ldd. Could anybody please give me a more reliable direction I should go with to get the same behaviour from both of the linkers? >> >> Target binary format is a 32-bit ELF executable, which is expected to consist of a single RWX segment starting from base 0x80000000. (Since I can reproduce the difference with at least mips, ppc32, x86, I attached the x86 linker script to the message as an example.) What is expected from the resulting binary (and what ld.bfd produces) is that no ELF headers are allocated in the address space, e.g. >> >> >> Elf file type is EXEC (Executable file) >> Entry point 0x80001a0f >> There are 1 program headers, starting at offset 52 >> >> Program Headers: >> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align >> LOAD 0x001000 0x80000000 0x80000000 0x08284 0x08284 RWE 0x1000 >> >> Section to Segment mapping: >> Segment Sections... >> 00 .text .rodata .eh_frame .data >> >> >> However, what ldd does is different. (To create a single segment I use --omagic argument, it works fine and is unrelated). The first segment is created at a lower address, with ELF headers in it, and then the actual text section exactly at 0x80000000: >> >> >> Elf file type is EXEC (Executable file) >> Entry point 0x80002670 >> There are 3 program headers, starting at offset 52 >> >> Program Headers: >> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align >> PHDR 0x000034 0x7ffff034 0x7ffff034 0x00060 0x00060 R 0x4 >> LOAD 0x000000 0x7ffff000 0x7ffff000 0x0a098 0x0a098 RWE 0x1000 >> GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x0 >> >> Section to Segment mapping: >> Segment Sections... >> 00 >> 01 .text .rodata .data >> 02 >> >> >> From what I understand if a linker script is used and the headers fail to allocate, then they should not be present in the resulting binary. However, it seems like ldd treats custom headers and automatically generated headers differently (well, that's at least how I see it at the moment). I think, if the headers are custom, they may not appear in the address space, otherwise they (always?) do. I came up with this conclusion because adding the following command appears to produce a correct binary: >> >> PHDRS >> { >> main PT_LOAD; >> } >> >> >> Elf file type is EXEC (Executable file) >> Entry point 0x80002670 >> There are 1 program headers, starting at offset 52 >> >> Program Headers: >> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align >> LOAD 0x001000 0x80000000 0x80000000 0x09098 0x09098 RWE 0x1000 >> >> Section to Segment mapping: >> Segment Sections... >> 00 .text .rodata .data >> >> >> However, this is not valid for at least ld.bfd, which produces an error in this case: >> ld: no sections assigned to phdrs >> >> At this step I feel a little confused, because even though I have a workaround, it is unclear whether both behaviours (with and without the mentioned workaround) are expected in the first place? Or might it actually be a bug in either of the linkers? Ideally I have some workaround that works in both of the linkers, but if it is not possible, I could continue going with PHDRS hack. >> >> Best regards, >> Vit >> >> >> >> >> >> _______________________________________________ >> 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/20171010/c7790feb/attachment.html>
Rui Ueyama via llvm-dev
2017-Oct-09 22:32 UTC
[llvm-dev] Understanding of ldd header allocation
Hi, I believe that is fixed in https://reviews.llvm.org/rL311586 thanks to Petr Hosek. Can you try to build the head of the development branch and see if your problem has been fixed? This is the build instruction: http://lld.llvm.org/#build On Mon, Oct 9, 2017 at 10:54 AM, vit9696 via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hello, > > I am currently switching to ldd from ld.bfd on a cross-platform embedded > project and am facing a behaviour difference when using the same linker > scripts with ld.bfd and ldd. Could anybody please give me a more reliable > direction I should go with to get the same behaviour from both of the > linkers? > > Target binary format is a 32-bit ELF executable, which is expected to > consist of a single RWX segment starting from base 0x80000000. (Since I can > reproduce the difference with at least mips, ppc32, x86, I attached the x86 > linker script to the message as an example.) What is expected from the > resulting binary (and what ld.bfd produces) is that no ELF headers are > allocated in the address space, e.g. > > > Elf file type is EXEC (Executable file) > Entry point 0x80001a0f > There are 1 program headers, starting at offset 52 > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > LOAD 0x001000 0x80000000 0x80000000 0x08284 0x08284 RWE 0x1000 > > Section to Segment mapping: > Segment Sections... > 00 .text .rodata .eh_frame .data > > > However, what ldd does is different. (To create a single segment I use > --omagic argument, it works fine and is unrelated). The first segment is > created at a lower address, with ELF headers in it, and then the actual > text section exactly at 0x80000000: > > > Elf file type is EXEC (Executable file) > Entry point 0x80002670 > There are 3 program headers, starting at offset 52 > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > PHDR 0x000034 0x7ffff034 0x7ffff034 0x00060 0x00060 R 0x4 > LOAD 0x000000 0x7ffff000 0x7ffff000 0x0a098 0x0a098 RWE 0x1000 > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x0 > > Section to Segment mapping: > Segment Sections... > 00 > 01 .text .rodata .data > 02 > > > From what I understand if a linker script is used and the headers fail to > allocate, then they should not be present in the resulting binary. However, > it seems like ldd treats custom headers and automatically generated headers > differently (well, that's at least how I see it at the moment). I think, if > the headers are custom, they may not appear in the address space, otherwise > they (always?) do. I came up with this conclusion because adding the > following command appears to produce a correct binary: > > PHDRS > { > main PT_LOAD; > } > > > Elf file type is EXEC (Executable file) > Entry point 0x80002670 > There are 1 program headers, starting at offset 52 > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > LOAD 0x001000 0x80000000 0x80000000 0x09098 0x09098 RWE 0x1000 > > Section to Segment mapping: > Segment Sections... > 00 .text .rodata .data > > > However, this is not valid for at least ld.bfd, which produces an error in > this case: > ld: no sections assigned to phdrs > > At this step I feel a little confused, because even though I have a > workaround, it is unclear whether both behaviours (with and without the > mentioned workaround) are expected in the first place? Or might it actually > be a bug in either of the linkers? Ideally I have some workaround that > works in both of the linkers, but if it is not possible, I could continue > going with PHDRS hack. > > Best regards, > Vit > > > > > > _______________________________________________ > 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/20171009/df1210ba/attachment.html>
vit9696 via llvm-dev
2017-Oct-10 14:48 UTC
[llvm-dev] Understanding of ldd header allocation
Hi, It’s great news to hear. I compiled the latest llvm toolchain and can confirm that the issue is fixed indeed and lld behaves normally. Thanks! Best reagars, Vit> 10 окт. 2017 г., в 1:32, Rui Ueyama <ruiu at google.com> написал(а): > > Hi, > > I believe that is fixed in https://reviews.llvm.org/rL311586 <https://reviews.llvm.org/rL311586> thanks to Petr Hosek. Can you try to build the head of the development branch and see if your problem has been fixed? This is the build instruction: http://lld.llvm.org/#build <http://lld.llvm.org/#build> > > On Mon, Oct 9, 2017 at 10:54 AM, vit9696 via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Hello, > > I am currently switching to ldd from ld.bfd on a cross-platform embedded project and am facing a behaviour difference when using the same linker scripts with ld.bfd and ldd. Could anybody please give me a more reliable direction I should go with to get the same behaviour from both of the linkers? > > Target binary format is a 32-bit ELF executable, which is expected to consist of a single RWX segment starting from base 0x80000000. (Since I can reproduce the difference with at least mips, ppc32, x86, I attached the x86 linker script to the message as an example.) What is expected from the resulting binary (and what ld.bfd produces) is that no ELF headers are allocated in the address space, e.g. > > > Elf file type is EXEC (Executable file) > Entry point 0x80001a0f > There are 1 program headers, starting at offset 52 > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > LOAD 0x001000 0x80000000 0x80000000 0x08284 0x08284 RWE 0x1000 > > Section to Segment mapping: > Segment Sections... > 00 .text .rodata .eh_frame .data > > > However, what ldd does is different. (To create a single segment I use --omagic argument, it works fine and is unrelated). The first segment is created at a lower address, with ELF headers in it, and then the actual text section exactly at 0x80000000: > > > Elf file type is EXEC (Executable file) > Entry point 0x80002670 > There are 3 program headers, starting at offset 52 > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > PHDR 0x000034 0x7ffff034 0x7ffff034 0x00060 0x00060 R 0x4 > LOAD 0x000000 0x7ffff000 0x7ffff000 0x0a098 0x0a098 RWE 0x1000 > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x0 > > Section to Segment mapping: > Segment Sections... > 00 > 01 .text .rodata .data > 02 > > > From what I understand if a linker script is used and the headers fail to allocate, then they should not be present in the resulting binary. However, it seems like ldd treats custom headers and automatically generated headers differently (well, that's at least how I see it at the moment). I think, if the headers are custom, they may not appear in the address space, otherwise they (always?) do. I came up with this conclusion because adding the following command appears to produce a correct binary: > > PHDRS > { > main PT_LOAD; > } > > > Elf file type is EXEC (Executable file) > Entry point 0x80002670 > There are 1 program headers, starting at offset 52 > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > LOAD 0x001000 0x80000000 0x80000000 0x09098 0x09098 RWE 0x1000 > > Section to Segment mapping: > Segment Sections... > 00 .text .rodata .data > > > However, this is not valid for at least ld.bfd, which produces an error in this case: > ld: no sections assigned to phdrs > > At this step I feel a little confused, because even though I have a workaround, it is unclear whether both behaviours (with and without the mentioned workaround) are expected in the first place? Or might it actually be a bug in either of the linkers? Ideally I have some workaround that works in both of the linkers, but if it is not possible, I could continue going with PHDRS hack. > > Best regards, > Vit > > > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <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/20171010/39243831/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171010/39243831/attachment.sig>