Date: Wed, 18 Jan 2017 15:41:50 -0800 From: Mark Millard <markmi@dsl-only.net> To: Roman Divacky <rdivacky@vlakno.cz> Cc: Ed Maste <emaste@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org> Subject: Re: /usr/bin/ld.lld on powerpc64: produces a.out for which: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374 Message-ID: <9023794B-0999-4F50-95DE-2D4156BC6E75@dsl-only.net> In-Reply-To: <20170118215420.GA65399@vlakno.cz> References: <20170116194035.GA20175@vlakno.cz> <2B1414C5-C56D-42F2-A1CB-4B1FE074667B@dsl-only.net> <43DBF7C7-6632-4906-BB37-FD00621AF857@dsl-only.net> <82402941-D1B2-4938-A43D-E21A390DE041@dsl-only.net> <F38C9607-5AB9-4BF9-BEC1-88EA2518A9CE@dsl-only.net> <27422F1B-6906-4D37-860A-D1BC8DC83BBF@dsl-only.net> <20170117195424.GA89237@vlakno.cz> <237EB920-0795-4B18-94D4-2EAC0FC76F01@dsl-only.net> <20170117215613.GA95258@vlakno.cz> <45D0BB1C-490A-4809-BAB1-F4E552FECEDD@dsl-only.net> <20170118215420.GA65399@vlakno.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Jan-18, at 1:54 PM, Roman Divacky <rdivacky@vlakno.cz> wrote:
> I think I got it all wrong. I think what lld is trying to achieve
> is to have the PLT entry to jump to GOT which references the real =
symbol.
=46rom what I've read: for code references the .got.plt section would
be involved when it exists, not the .got section.
> For some reason, GOT is empty, in our case.
I think that I've already explained this: lld produces two different
sections instead of just one .got section: .got and .got.plt .
.got is now for only global variables. (These can be in the
RELRO region: read-only after upfront relocation.) My program
had no global variables. If you want I can change it to have one
and use it so that the .got will not be empty.
.got.plt is for code references that allow lazy relocation.
(These can not being the the RELRO region.) Having the global
variable would not change this from what I can tell.
In the older toolchain these were both in the .got section and
the global variable relocations could not be in the RELRO region
because of the mixing in one section.
> I believe this might be caused
> by a relocation thats wrongly mapped to R_ABS in =
PPC64TargetInfo::getRelExpr().
That is not it from what I can tell reading about what the .got.plt
section is for and why it was split from the .got section.
I think I'll add a global variable and use it so that their is no
question what goes in the .got section instead of having no examples.
I think you are not going in the right direction now for what the
.got section is for as lld is producing things for powerpc64 (not
that I'm an expert in the older or newer techniques).
> Mark, can you apply this patch and rerun the linking and send me back =
what
> relocations are applied to what symbols? Or even, if there's an =
unhandled
> relocation, try to adjust the switch and rerun your test?=20
I think that I will first add the global variable and its use
and show what the last change with Plt instead of Got ends
up looking like --but with your log notices added.
Then I'll retry with the Plt use reverted.
> Thanks
>=20
> Index: ../tools/lld/ELF/Target.cpp
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- ../tools/lld/ELF/Target.cpp (revision 292428)
> +++ ../tools/lld/ELF/Target.cpp (working copy)
> @@ -1075,7 +1075,8 @@
> }
>=20
> PPC64TargetInfo::PPC64TargetInfo() {
> - PltRel =3D GotRel =3D R_PPC64_GLOB_DAT;
> + GotRel =3D R_PPC64_GLOB_DAT;
> + PltRel =3D R_PPC64_JMP_SLOT;
> RelativeRel =3D R_PPC64_RELATIVE;
> GotEntrySize =3D 8;
> GotPltEntrySize =3D 8;
> @@ -1114,8 +1115,10 @@
> }
>=20
> RelExpr PPC64TargetInfo::getRelExpr(uint32_t Type, const SymbolBody =
&S) const {
> + llvm::outs() << "Type =3D " << Type << ", name =3D " << S.getName() =
<< "\n";
> switch (Type) {
> default:
> + llvm::outs() << "Unhandled type =3D " << Type << "\n";
> return R_ABS;
> case R_PPC64_TOC16:
> case R_PPC64_TOC16_DS:
It may be a bit before I get the Plt and/or Got examples done.
I might report the Plt case first and separately, later report
the Got case.
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
On Tue, Jan 17, 2017 at 09:38:07PM -0800, Mark Millard wrote:
> Using the new changed line (Plt use now):
>=20
> uint64_t TocVA =3D Out<ELF64BE>::Plt->getVA();
>=20
> changed the behavior and it gets farther for
> -fuse-ld=3Dlld based linking. But it is r2 leading
> to r3 content that is dereferenced and 8(r3) fails
> this time. This was in the process of finding
> the new r2 value for the following bctrl.
> r2=3D=3D0x10018560 initially in __do_global_ctors_aux
> seems wrong. If so then objlist_call_init produced
> a wrong r2 value.
>=20
> [I've no clue if this is what you expected from
> the Plt experiment or not.]
>=20
> Details. . .
>=20
> # /usr/local/bin/gdb a.out
> GNU gdb (GDB) 7.11.1 [GDB v7.11.1 for FreeBSD]
> . . .
> Reading symbols from a.out...done.
> (gdb) run
> Starting program: /root/c_tests/a.out=20
>=20
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000100104a8 in .__do_global_ctors_aux ()
> (gdb) bt
> #0 0x00000000100104a8 in .__do_global_ctors_aux ()
> #1 0x0000000010010518 in ._init ()
> #2 0x000000005002ac78 in objlist_call_init (list=3D<optimized out>, =
lockstate=3D<optimized out>) at /usr/src/libexec/rtld-elf/rtld.c:2541
> #3 0x0000000050029fa8 in _rtld (sp=3D<optimized out>, =
exit_proc=3D<optimized out>, objp=3D<optimized out>) at =
/usr/src/libexec/rtld-elf/rtld.c:668
> #4 0x00000000500279b0 in ._rtld_start () at =
/usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:83
> Backtrace stopped: frame did not save the PC
> (gdb) disass
> Dump of assembler code for function .__do_global_ctors_aux:
> 0x0000000010010470 <+0>: mflr r0
> 0x0000000010010474 <+4>: std r31,-8(r1)
> 0x0000000010010478 <+8>: std r0,16(r1)
> 0x000000001001047c <+12>: stdu r1,-128(r1)
> 0x0000000010010480 <+16>: addis r3,r2,-1 <<<<<=3D=3D=3D=3D =
Note: r3 derives from r2
> 0x0000000010010484 <+20>: mr r31,r1
> 0x0000000010010488 <+24>: addi r3,r3,32464
> 0x000000001001048c <+28>: std r30,112(r31)
> 0x0000000010010490 <+32>: ld r3,-8(r3)
> 0x0000000010010494 <+36>: cmpdi r3,-1
> 0x0000000010010498 <+40>: beq 0x100104d4 =
<.__do_global_ctors_aux+100>
> 0x000000001001049c <+44>: addis r4,r2,-1
> 0x00000000100104a0 <+48>: addi r4,r4,32464
> 0x00000000100104a4 <+52>: addi r30,r4,-8
> =3D> 0x00000000100104a8 <+56>: ld r4,8(r3) <<<<<=3D=3D=3D=
=3D Note: 8(r3) fails.
> 0x00000000100104ac <+60>: ld r11,16(r3)
> 0x00000000100104b0 <+64>: ld r3,0(r3)
> 0x00000000100104b4 <+68>: std r2,40(r1)
> 0x00000000100104b8 <+72>: mr r2,r4 <<<<<=3D=3D=3D=3D =
Note: 8(r3) result should have been the new r2 value
> 0x00000000100104bc <+76>: mtctr r3
> 0x00000000100104c0 <+80>: bctrl
> 0x00000000100104c4 <+84>: ld r2,40(r1)
> 0x00000000100104c8 <+88>: ldu r3,-8(r30)
> 0x00000000100104cc <+92>: cmpdi r3,-1
> 0x00000000100104d0 <+96>: bne 0x100104a8 =
<.__do_global_ctors_aux+56>
> 0x00000000100104d4 <+100>: ld r30,112(r31)
> 0x00000000100104d8 <+104>: addi r1,r1,128
> 0x00000000100104dc <+108>: ld r0,16(r1)
> 0x00000000100104e0 <+112>: ld r31,-8(r1)
> 0x00000000100104e4 <+116>: mtlr r0
> 0x00000000100104e8 <+120>: blr
> 0x00000000100104ec <+124>: .long 0x0
> 0x00000000100104f0 <+128>: .long 0x0
> 0x00000000100104f4 <+132>: .long 0x0
> End of assembler dump.
> (gdb) info registers
> r0 0x10010518 268502296
> r1 0xffffffffffffcbf0 18446744073709538288
> r2 0x10018560 268535136
> r3 0x7ca903a64e800421 8982714944583631905
> r4 0x10010430 268502064
> r5 0x100300d0 268632272
> r6 0x50043ab0 1342454448
> r7 0x50067f00 1342603008
> r8 0xffffffffffffdfcc 18446744073709543372
> r9 0x0 0
> r10 0x0 0
> r11 0x0 0
> r12 0xffffffffffffdfd0 18446744073709543376
> r13 0x50057010 1342533648
> r14 0x0 0
> r15 0x0 0
> r16 0x50047f00 1342471936
> r17 0x500613e0 1342575584
> r18 0x50253388 1344615304
> r19 0x2 2
> r20 0x0 0
> r21 0x9 9
> r22 0x0 0
> r23 0x40000000000000 18014398509481984
> r24 0x5004a100 1342480640
> r25 0x5004c400 1342489600
> r26 0xffffffffffffcd18 18446744073709538584
> r27 0xffffffffffffcd3c 18446744073709538620
> r28 0xffffffffffffcd3c 18446744073709538620
> r29 0x0 0
> r30 0x10010428 268502056
> r31 0xffffffffffffcbf0 18446744073709538288
> pc 0x100104a8 0x100104a8 <.__do_global_ctors_aux+56>
> msr <unavailable>
> cr 0x48200c00 1210059776
> lr 0x10010518 0x10010518 <._init+24>
> ctr 0x10010500 268502272
> xer 0x20000000 536870912
> (gdb) info file
> Symbols from "/root/c_tests/a.out".
> Native process:
> Using the running image of child LWP 100093 of process 1091.
> While running this, GDB does not access memory from...
> Local exec file:
> `/root/c_tests/a.out', file type elf64-powerpc-freebsd.
> Entry point: 0x100300a0
> 0x0000000010000270 - 0x0000000010000285 is .interp
> 0x0000000010000288 - 0x00000000100002b8 is .note.tag
> 0x00000000100002b8 - 0x00000000100002b9 is .rodata
> 0x00000000100002bc - 0x00000000100002bc is .eh_frame
> 0x00000000100002c0 - 0x0000000010000368 is .dynsym
> 0x0000000010000368 - 0x0000000010000376 is .gnu.version
> 0x0000000010000378 - 0x0000000010000398 is .gnu.version_r
> 0x0000000010000398 - 0x00000000100003d8 is .hash
> 0x00000000100003d8 - 0x000000001000041a is .dynstr
> 0x0000000010000420 - 0x0000000010000468 is .rela.plt
> 0x0000000010000468 - 0x0000000010000474 is .eh_frame_hdr
> 0x0000000010010000 - 0x00000000100104f8 is .text
> 0x0000000010010500 - 0x000000001001052c is .init
> 0x0000000010010530 - 0x0000000010010554 is .fini
> 0x0000000010010560 - 0x00000000100105c0 is .plt
> 0x0000000010020000 - 0x0000000010020010 is .ctors
> 0x0000000010020010 - 0x0000000010020020 is .dtors
> 0x0000000010020020 - 0x0000000010020028 is .jcr
> 0x0000000010020028 - 0x0000000010020138 is .dynamic
> 0x0000000010020138 - 0x0000000010020138 is .got
> 0x0000000010030000 - 0x0000000010030019 is .data
> 0x0000000010030020 - 0x0000000010030050 is .got.plt
> 0x0000000010030050 - 0x00000000100300a0 is .toc
> 0x00000000100300a0 - 0x0000000010030160 is .opd
> 0x0000000010030160 - 0x0000000010030170 is .bss
> 0x0000000050020158 - 0x0000000050020228 is .hash in =
/libexec/ld-elf.so.1
> 0x0000000050020228 - 0x0000000050020540 is .dynsym in =
/libexec/ld-elf.so.1
> 0x0000000050020540 - 0x00000000500206b6 is .dynstr in =
/libexec/ld-elf.so.1
> 0x00000000500206b6 - 0x00000000500206f8 is .gnu.version in =
/libexec/ld-elf.so.1
> 0x00000000500206f8 - 0x0000000050020808 is .gnu.version_d in =
/libexec/ld-elf.so.1
> 0x0000000050020808 - 0x0000000050027960 is .rela.dyn in =
/libexec/ld-elf.so.1
> 0x0000000050027960 - 0x0000000050045a04 is .text in =
/libexec/ld-elf.so.1
> 0x0000000050045a04 - 0x00000000500484a3 is .rodata in =
/libexec/ld-elf.so.1
> 0x00000000500484a4 - 0x00000000500484a4 is .eh_frame in =
/libexec/ld-elf.so.1
> 0x000000005005cf50 - 0x000000005005cf58 is .fini_array in =
/libexec/ld-elf.so.1
> 0x000000005005cf58 - 0x000000005005d260 is .data.rel.ro in =
/libexec/ld-elf.so.1
> 0x000000005005d260 - 0x000000005005d3b0 is .dynamic in =
/libexec/ld-elf.so.1
> 0x000000005005d3b0 - 0x000000005005ff00 is .opd in =
/libexec/ld-elf.so.1
> 0x000000005005ff00 - 0x000000005005ff08 is .got in =
/libexec/ld-elf.so.1
> 0x0000000050060000 - 0x0000000050060628 is .data in =
/libexec/ld-elf.so.1
> 0x0000000050060628 - 0x0000000050061478 is .bss in =
/libexec/ld-elf.so.1
> 0x00000000500621c8 - 0x00000000500672b0 is .hash in =
/lib/libc.so.7
> 0x00000000500672b0 - 0x0000000050079778 is .dynsym in =
/lib/libc.so.7
> 0x0000000050079778 - 0x0000000050080846 is .dynstr in =
/lib/libc.so.7
> 0x0000000050080846 - 0x00000000500820ac is .gnu.version in =
/lib/libc.so.7
> 0x00000000500820b0 - 0x00000000500821c0 is .gnu.version_d in =
/lib/libc.so.7
> 0x00000000500821c0 - 0x00000000500c2678 is .rela.dyn in =
/lib/libc.so.7
> 0x00000000500c2678 - 0x00000000500c7868 is .rela.plt in =
/lib/libc.so.7
> 0x00000000500c7870 - 0x00000000500c789c is .init in =
/lib/libc.so.7
> 0x00000000500c78a0 - 0x0000000050227ca0 is .text in =
/lib/libc.so.7
> 0x0000000050227ca0 - 0x0000000050227cc4 is .fini in =
/lib/libc.so.7
> 0x0000000050227d00 - 0x000000005023b606 is .rodata in =
/lib/libc.so.7
> 0x000000005023b608 - 0x000000005023b6ec is .eh_frame_hdr in =
/lib/libc.so.7
> 0x000000005023b6f0 - 0x000000005023bad4 is .eh_frame in =
/lib/libc.so.7
> 0x0000000050253318 - 0x0000000050253380 is .tdata in =
/lib/libc.so.7
> 0x0000000050253380 - 0x0000000050253390 is .tbss in =
/lib/libc.so.7
> 0x0000000050253380 - 0x0000000050253390 is .init_array in =
/lib/libc.so.7
> 0x0000000050253390 - 0x0000000050253398 is .fini_array in =
/lib/libc.so.7
> 0x0000000050253398 - 0x00000000502533a8 is .ctors in =
/lib/libc.so.7
> 0x00000000502533a8 - 0x00000000502533b8 is .dtors in =
/lib/libc.so.7
> 0x00000000502533b8 - 0x00000000502533c0 is .jcr in =
/lib/libc.so.7
> 0x00000000502533c0 - 0x0000000050258a90 is .data.rel.ro in =
/lib/libc.so.7
> 0x0000000050258a90 - 0x0000000050258c60 is .dynamic in =
/lib/libc.so.7
> 0x0000000050258c60 - 0x000000005026f8f8 is .opd in =
/lib/libc.so.7
> 0x000000005026f900 - 0x0000000050271f98 is .got in =
/lib/libc.so.7
> 0x0000000050272000 - 0x0000000050277208 is .plt in =
/lib/libc.so.7
> 0x0000000050277208 - 0x000000005027b0b0 is .data in =
/lib/libc.so.7
> 0x000000005027b0b0 - 0x0000000050294738 is .bss in =
/lib/libc.so.7
>=20
>=20
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
>=20
> On 2017-Jan-17, at 1:56 PM, Roman Divacky <rdivacky at vlakno.cz> =
wrote:
>=20
>> Go with Out.
>>=20
>> On Tue, Jan 17, 2017 at 01:53:14PM -0800, Mark Millard wrote:
>>> On 2017-Jan-17, at 11:54 AM, Roman Divacky <rdivacky at vlakno.cz> =
wrote:
>>>=20
>>> . . .
>>>> I wonder if it doesnt work because of my first patch (the one to =
turn GOT
>>>> reloc into PLT one).
>>>>=20
>>>> LLD understands that we use GOT as TOC (which was true before my =
patch),
>>>> I wonder if something like this:
>>>>=20
>>>> ndex: tools/lld/ELF/Target.cpp
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>> --- tools/lld/ELF/Target.cpp (revision 292071)
>>>> +++ tools/lld/ELF/Target.cpp (working copy)
>>>> @@ -1070,7 +1070,8 @@
>>>> }
>>>>=20
>>>> PPC64TargetInfo::PPC64TargetInfo() {
>>>> - PltRel =3D GotRel =3D R_PPC64_GLOB_DAT;
>>>> + GotRel =3D R_PPC64_GLOB_DAT;
>>>> + PltRel =3D R_PPC64_JMP_SLOT;
>>>> RelativeRel =3D R_PPC64_RELATIVE;
>>>> GotEntrySize =3D 8;
>>>> GotPltEntrySize =3D 8;
>>>> @@ -1099,7 +1100,7 @@
>>>> // TOC starts where the first of these sections starts. We always =
create a
>>>> // .got when we see a relocation that uses it, so for us the start =
is always
>>>> // the .got.
>>>> - uint64_t TocVA =3D In<ELF64BE>::Got->getVA();
>>>> + uint64_t TocVA =3D In<ELF64BE>::Plt->getVA();
>>>>=20
>>>> // Per the ppc64-elf-linux ABI, The TOC base is TOC value plus =
0x8000
>>>> // thus permitting a full 64 Kbytes segment. Note that the glibc =
startup
>>>=20
>>> The modern 3.9.1 source does not match for the last. Note the
>>> "Out" vs. "In" below ("svnlite status" does not show my source
>>> as different in this area):
>>>=20
>>> uint64_t getPPC64TocBase() {
>>> // The TOC consists of sections .got, .toc, .tocbss, .plt in that =
order. The
>>> // TOC starts where the first of these sections starts. We always =
create a
>>> // .got when we see a relocation that uses it, so for us the start =
is always
>>> // the .got.
>>> uint64_t TocVA =3D Out<ELF64BE>::Got->getVA();
>>>=20
>>> // Per the ppc64-elf-linux ABI, The TOC base is TOC value plus =
0x8000
>>> // thus permitting a full 64 Kbytes segment. Note that the glibc =
startup
>>> // code (crt1.o) assumes that you can get from the TOC base to the
>>> // start of the .toc section with only a single (signed) 16-bit =
relocation.
>>> return TocVA + PPC64TocOffset;
>>> }
>>>=20
>>> [Also the "// TOC . . ." comment is at line 1005 (given the prior
>>> GotRel vs. PltRel split into separate lines).]
>>>=20
>>> Which should I use?: In vs. Out
>>>=20
>>>> would make any difference? It's not correct but might shed some =
light on what needs to be done
>>>> if I am right.
>>>=20
>>> Separately if I understand the change you are picking out which =
section
>>> is first of .got, .toc, .tocbss, .plt (.got.plt as well?). But for =
the
>>> order of things that would still make the .ctors, .dtors, .jcr, =
.dynamic,
>>> and .data sections as being inside the TOC and taking TOC address =
range
>>> space:
>>>=20
>>> 0x0000000010010560 - 0x00000000100105c0 is .plt =
<<<<<=3D=3D=3D=3D=3D NOTE!!!!
>>> 0x0000000010020000 - 0x0000000010020010 is .ctors
>>> 0x0000000010020010 - 0x0000000010020020 is .dtors
>>> 0x0000000010020020 - 0x0000000010020028 is .jcr
>>> 0x0000000010020028 - 0x0000000010020138 is .dynamic
>>> 0x0000000010020138 - 0x0000000010020138 is .got =
<<<<<=3D=3D=3D=3D=3D NOTE!!!!
>>> 0x0000000010030000 - 0x0000000010030019 is .data
>>> 0x0000000010030020 - 0x0000000010030050 is .got.plt =
<<<<<=3D=3D=3D=3D=3D NOTE!!!!
>>> 0x0000000010030050 - 0x00000000100300a0 is .toc =
<<<<<=3D=3D=3D=3D=3D NOTE!!!!
>>>=20
>>> Is that expected/desired/allowed?
>>>=20
>>>> Could you explore this please?
>>>=20
>>> After you report for sure for In vs. Out I'll take a stab
>>> at it.
>>>=20
>>> =3D=3D=3D
>>> Mark Millard
>>> markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9023794B-0999-4F50-95DE-2D4156BC6E75>