From owner-freebsd-toolchain@freebsd.org Mon Jan 16 21:39:31 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8A63CB3E89 for ; Mon, 16 Jan 2017 21:39:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-12.reflexion.net [208.70.210.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8788E15A1 for ; Mon, 16 Jan 2017 21:39:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10226 invoked from network); 16 Jan 2017 21:39:50 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 16 Jan 2017 21:39:50 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Mon, 16 Jan 2017 16:39:23 -0500 (EST) Received: (qmail 27579 invoked from network); 16 Jan 2017 21:39:23 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 16 Jan 2017 21:39:23 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id E38A1EC8B1E; Mon, 16 Jan 2017 13:39:22 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) 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 From: Mark Millard In-Reply-To: <20170116194035.GA20175@vlakno.cz> Date: Mon, 16 Jan 2017 13:39:22 -0800 Cc: FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <2B1414C5-C56D-42F2-A1CB-4B1FE074667B@dsl-only.net> References: <20170111194844.GA16135@vlakno.cz> <8242A7B9-7ED3-4861-8209-F3728113D188@dsl-only.net> <20170111210658.GA20265@vlakno.cz> <20170112192223.GA49469@vlakno.cz> <932E3C38-B226-4BF1-B587-5A2D5EA19300@dsl-only.net> <20170116194035.GA20175@vlakno.cz> To: Roman Divacky , Ed Maste X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 21:39:31 -0000 On 2017-Jan-16, at 11:40 AM, Roman Divacky = wrote: > I think the TOC (.got + .plt) has to be contiguous in memory. The = on-disk > layout is not that important. I showed the address column that I would expect to accurately reflect = addresses to load to in the process. I also showed the Offset Align which would be = relative to whatever base was used (even if different) as far as I can tell. (Later in repsonse t your question I show what I expect is a sufficient confirmation.) Note: objdump and readelf agree (VMA and LMA). Here is the objdump equivalent: Sections: Idx Name Size VMA LMA File off = Algn . . . 9 .rela.plt 00000048 0000000010000420 0000000010000420 00000420 = 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA . . . 14 .plt 00000060 0000000010010560 0000000010010560 00010560 = 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE . . . 19 .got 00000000 0000000010020138 0000000010020138 00020138 = 2**3 CONTENTS, ALLOC, LOAD, DATA . . . 21 .got.plt 00000030 0000000010030020 0000000010030020 00030020 = 2**3 CONTENTS, ALLOC, LOAD, DATA 22 .toc 00000050 0000000010030050 0000000010030050 00030050 = 2**3 CONTENTS, ALLOC, LOAD, DATA . . . > Can you check whats the difference of the in-memory TOC between lld = and ld.bfd? gdb reports agreement with the addresses listed by the likes of objdump = for the symbols it reports. There are examples from sections .note.tag, = .eh_frame, .ctors, .dtors, .jcr, .dynamic, .data, .pod, and .bss . None of these = sections move. So I expect the other sections do not move either. Below I compare objdump symbols reporting to gdb reporting of what = symbol is at an address, at least one address for each one of those sections with = a symbol. Here is what objdump shows for assigned symbols (sorted): (I've inserted some comments about some other sections that have no symbols based on the addresses from objdump and readelf.) 0000000010000288 l O .note.tag 0000000000000018 = abitag 00000000100002a0 l O .note.tag 0000000000000018 = crt_noinit_tag 00000000100002bb l O .eh_frame 0000000000000004 = __FRAME_END__ .rela.plt fits between here: 0000000010000420 (start) .plt fits between here : 0000000010010560 (start) 0000000010020000 l O .ctors 0000000000000008 = __CTOR_LIST__ 0000000010020008 l O .ctors 0000000000000008 = __CTOR_END__ 0000000010020010 l O .dtors 0000000000000008 = __DTOR_LIST__ 0000000010020018 l O .dtors 0000000000000008 = __DTOR_END__ 0000000010020020 l O .jcr 0000000000000000 = __JCR_LIST__ 0000000010020020 l O .jcr 0000000000000008 = __JCR_END__ 0000000010020028 l .dynamic 0000000000000000 = .hidden _DYNAMIC .got fits between here : 0000000010020138 (start and end: size zero) 0000000010030000 g O .data 0000000000000008 __progname 0000000010030008 l O .data 0000000000000008 .hidden = __dso_handle 0000000010030010 l O .data 0000000000000008 = __do_global_dtors_aux.p 0000000010030018 l O .data 0000000000000001 = __do_global_dtors_aux.completed .got.plt fits between here : 0000000010030020 (start) .toc fits between here : 0000000010030050 (start) 00000000100300a0 g F .opd 0000000000000264 _start 00000000100300b8 l F .opd 00000000000000d0 finalizer 00000000100300d0 l F .opd 0000000000000000 .hidden = _init 00000000100300e8 l F .opd 0000000000000000 .hidden = _fini 0000000010030100 l F .opd 00000000000000a4 = __do_global_dtors_aux 0000000010030118 l F .opd 000000000000007c = frame_dummy 0000000010030130 g F .opd 000000000000001c main 0000000010030148 l F .opd 0000000000000088 = __do_global_ctors_aux 0000000010030160 g O .bss 0000000000000008 = __ps_strings 0000000010030168 g O .bss 0000000000000008 environ 0000000010030170 g *ABS* 0000000000000000 _end Examples of gdb reporting symbol information for some of those = addresses: (gdb) info symbol 0x0000000010000288 abitag in section .note.tag (gdb) info symbol 0x00000000100002a0 crt_noinit_tag in section .note.tag (gdb) info symbol 0x00000000100002a4 crt_noinit_tag + 4 in section .note.tag (gdb) info symbol 0x0000000010020008 __CTOR_END__ in section .ctors (gdb) info symbol 0x0000000010020010 __DTOR_LIST__ in section .dtors (gdb) info symbol 0x0000000010020020 __JCR_END__ in section .jcr (gdb) info symbol 0x0000000010020028 _DYNAMIC in section .dynamic (gdb) info symbol 0x0000000010030010 __do_global_dtors_aux.p in section .data (gdb) info symbol 0x00000000100300a0 _start in section .opd (gdb) info symbol 0x0000000010030130 main in section .opd (gdb) info symbol 0x0000000010030160 __ps_strings in section .bss ld.lld (as configured?) just does not set up for the sections to have the property: .got, .toc, .tocbss, .plt in that order (in memory) and ld.lld (as configured?) puts out sections that ld.bfd does not: .got.plt .toc I'd guess that ld.lld has build-time and/or run-time configuration requirements in order for its results to basically match what ld.bfd does for the same input files --if it even can. =3D=3D=3D Mark Millard markmi at dsl-only.net On Fri, Jan 13, 2017 at 02:07:00PM -0800, Mark Millard wrote: > Just an FYI: >=20 > elfdump -a (from -r311950) does not dump .plt or .got.plt or .toc : >=20 > # elfdump -a a.out | egrep "(got|toc|plt|:$)" | more > elf header: > program header: > section header: > sh_name: .rela.plt > sh_name: .plt > sh_name: .got > sh_name: .got.plt > sh_name: .toc > interp: > symbol table (.dynsym): > relocation with addend (.rela.plt): > dynamic: > global offset table: > symbol table (.symtab): >=20 > (The "global offset table" was empty but its title was listed.) >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2017-Jan-12, at 5:58 PM, Mark Millard = wrote: >=20 > On 2017-Jan-12, at 11:22 AM, Roman Divacky = wrote: >=20 >> Can you check if the TOC is correct? LLD assumes this: >>=20 >> static uint64_t PPC64TocOffset =3D 0x8000; >>=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 In::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 > [I warn that I'm outside familiar territory here.] >=20 > If I understand the 1st comment right the following does not look > like a match for -fuse-dl=3Dlld (readelf -a output): >=20 > Section Headers: > [Nr] Name Type Address Offset > Size EntSize Flags Link Info Align > [ 0] NULL 0000000000000000 00000000 > 0000000000000000 0000000000000000 0 0 0 > . . . > [10] .rela.plt RELA 0000000010000420 00000420 > 0000000000000048 0000000000000018 A 5 0 8 > . . . > [15] .plt PROGBITS 0000000010010560 00010560 > 0000000000000060 0000000000000000 AX 0 0 16 > . . . > [20] .got PROGBITS 0000000010020138 00020138 > 0000000000000000 0000000000000000 WA 0 0 8 > . . . > [22] .got.plt PROGBITS 0000000010030020 00030020 > 0000000000000030 0000000000000000 WA 0 0 8 > . . . > [23] .toc PROGBITS 0000000010030050 00030050 > 0000000000000050 0000000000000000 WA 0 0 8 >=20 > Possibly contributing reasons: >=20 > A) .got is not "first" of the 4 sections (by Address or by [Nr]). > (.got is listed as zero size as well) > B) There is no reference to .got.plt in the comment. > C) .got and .toc have .got.plt and other things between > -- and .got and .got.plt have stuff between. > D) There is no .tocbss at all (guess: optional so possibly okay). > E) .plt is before .got by address and by [Nr] > (it is als not next to .got or .got.plt or .toc). > F) There is no reference to .got.plt in the comment. > G) In general there are other things between the sections > making them spread over a wider address range. >=20 > [I guess that .rela.plt does not matter but I showed it > in case I'm wrong.] >=20 > Another potential issue is .plt being PROGBITS instead of > NOBITS (see below). Related is AX flags above vs. WA > flags below being a potential issue. >=20 >=20 > By contrast for -fuse-dl-bfd I see: >=20 > Section Headers: > [Nr] Name Type Address Offset > Size EntSize Flags Link Info Align > [ 0] NULL 0000000000000000 00000000 > 0000000000000000 0000000000000000 0 0 0 > . . . > [ 8] .rela.plt RELA 0000000010000370 00000370 > 0000000000000048 0000000000000018 A 4 22 8 > . . . > [21] .got PROGBITS 0000000010010c48 00000c48 > 0000000000000058 0000000000000008 WA 0 0 8 > [22] .plt NOBITS 0000000010010ca0 00000ca0 > 0000000000000060 0000000000000018 WA 0 0 8 >=20 > So no .toc or .tocbase sections. >=20 > But .got and .plt are next to each other with .got first > (by address and by [Nr]). This would fit the comments if > .toc and .tocbss are optional --and apparently they are. >=20 > So my guess is that -fuse-dl-bfd looks to be as expected, > unlike -fuse-dl=3Dlld . >=20 >=20 >> Perhaps thats not true on FreeBSD? Especially the hardcoded constant = seems suspicious. >> When it comes to the actual PLT entry, there's this comment in the = code: >>=20 >> // FIXME: What we should do, in theory, is get the offset of the = function >> // descriptor in the .opd section, and use that as the offset from = %r2 (the >> // TOC-base pointer). Instead, we have the GOT-entry offset, and that = will >> // be a pointer to the function descriptor in the .opd section. Using >> // this scheme is simpler, but requires an extra indirection per PLT = dispatch. >>=20 >> So I think that while it's different it might not be wrong. What = might be wrong >> is the TOC entry (either it's content or it's position). >>=20 >> I suspect there might be some Linux vs FreeBSD difference that = prevents this from working. >>=20 >> Roman >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On Thu, Jan 12, 2017 at 12:37:53AM -0800, Mark Millard wrote: >> On 2017-Jan-11, at 1:23 PM, Ed Maste wrote: >>=20 >>> On 11 January 2017 at 21:06, Roman Divacky = wrote: >>>> Looks like a progress :) Three questions... >>>>=20 >>>> Is the readelf -a reasonable now? >>>=20 >>> FYI, I just committed an ELF Tool Chain fix (r311941) so readelf >>> should display the relocation types properly now. >>=20 >> Thanks. I updated to -r311950 to pick this up. >>=20 >>>> If you compile with -g, does the >>>> backtrace make a bit more sense? And finally, can you try to = "nexti/stepi" in gdb from >>>> _start to see where things go wrong? Possibly doing it both for ld = linked a.out >>>> and lld linked a.out and compare where things differ. >>=20 >> I had compiled with -g. It never gets to main. . . >>=20 >> # /usr/local/bin/gdb a.out >> . . . >> Reading symbols from a.out...done. >> (gdb) start >> Temporary breakpoint 1 at 0x1001045c: file main.c, line 3. >> Starting program: /root/c_tests/a.out=20 >>=20 >> Program received signal SIGSEGV, Segmentation fault. >> 0x000000001001056c in ?? () >>=20 >> Note that the temporary breakpoint is never hit. >>=20 >> (gdb) bt >> #0 0x000000001001056c in ?? () >> #1 0x00000000100100d8 in ?? () >> #2 0x00000000500279b0 in ._rtld_start () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 >> Backtrace stopped: frame did not save the PC >>=20 >> (gdb) up 2 >> #2 0x00000000500279b0 in ._rtld_start () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 >> 104 blrl /* _start(argc, argv, envp, obj, cleanup, = ps_strings) */ >> (gdb) disass >> Dump of assembler code for function ._rtld_start: >> 0x0000000050027930 <+0>: stdu r1,-144(r1) >> 0x0000000050027934 <+4>: std r3,96(r1) >> 0x0000000050027938 <+8>: std r4,104(r1) >> 0x000000005002793c <+12>: std r5,112(r1) >> 0x0000000050027940 <+16>: std r8,136(r1) >> 0x0000000050027944 <+20>: bl 0x50027950 <._rtld_start+32> >> 0x0000000050027948 <+24>: .long 0x0 >> 0x000000005002794c <+28>: .long 0x30e40 >> 0x0000000050027950 <+32>: mflr r3 >> 0x0000000050027954 <+36>: ld r4,0(r3) >> 0x0000000050027958 <+40>: add r3,r4,r3 >> 0x000000005002795c <+44>: ld r4,-32768(r2) >> 0x0000000050027960 <+48>: subf r4,r4,r2 >> 0x0000000050027964 <+52>: bl 0x50027c64 >> 0x0000000050027968 <+56>: nop >> 0x000000005002796c <+60>: ld r4,104(r1) >> 0x0000000050027970 <+64>: addi r3,r4,-8 >> 0x0000000050027974 <+68>: addi r4,r1,128 >> 0x0000000050027978 <+72>: addi r5,r1,120 >> 0x000000005002797c <+76>: bl 0x50028608 <_rtld> >> 0x0000000050027980 <+80>: nop >> 0x0000000050027984 <+84>: ld r2,8(r3) >> 0x0000000050027988 <+88>: ld r11,16(r3) >> 0x000000005002798c <+92>: ld r3,0(r3) >> 0x0000000050027990 <+96>: mtlr r3 >> 0x0000000050027994 <+100>: ld r3,96(r1) >> 0x0000000050027998 <+104>: ld r4,104(r1) >> 0x000000005002799c <+108>: ld r5,112(r1) >> 0x00000000500279a0 <+112>: ld r6,120(r1) >> 0x00000000500279a4 <+116>: ld r7,128(r1) >> 0x00000000500279a8 <+120>: ld r8,136(r1) >> 0x00000000500279ac <+124>: blrl >> =3D> 0x00000000500279b0 <+128>: li r0,1 >> 0x00000000500279b4 <+132>: sc =20 >> 0x00000000500279b8 <+136>: nop >> 0x00000000500279bc <+140>: nop >> End of assembler dump. >>=20 >> So setting a breakpoint at 0x00000000500279ac and >> trying again: >>=20 >> (gdb) run >> Starting program: /root/c_tests/a.out=20 >>=20 >> Breakpoint 3, ._rtld_start () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 >> 104 blrl /* _start(argc, argv, envp, obj, cleanup, = ps_strings) */ >> (gdb) info registers >> r0 0x50027980 1342339456 >> r1 0xffffffffffffdaf0 18446744073709542128 >> r2 0x10028138 268599608 >> r3 0x1 1 >> r4 0xffffffffffffdbb8 18446744073709542328 >> r5 0xffffffffffffdbc8 18446744073709542344 >> r6 0x5004c000 1342488576 >> r7 0x50058b30 1342540592 >> r8 0x0 0 >> r9 0x0 0 >> r10 0x0 0 >> r11 0x0 0 >> r12 0x20000000 536870912 >> r13 0x50057010 1342533648 >> r14 0x0 0 >> r15 0x0 0 >> r16 0x0 0 >> r17 0x0 0 >> r18 0x0 0 >> r19 0x0 0 >> r20 0x0 0 >> r21 0x0 0 >> r22 0x0 0 >> r23 0x0 0 >> r24 0x0 0 >> r25 0x0 0 >> r26 0x0 0 >> r27 0x0 0 >> r28 0x0 0 >> r29 0x0 0 >> r30 0x0 0 >> r31 0x0 0 >> pc 0x500279ac 0x500279ac <._rtld_start+124> >> msr >> cr 0x22000c00 570428416 >> lr 0x10010000 0x10010000 >> ctr 0x50043a80 1342454400 >> xer 0x20000000 536870912 >> (gdb) stepi >> 0x0000000010010000 in ?? () >>=20 >> and that is effectively at ._start . >>=20 >> NOTE: There is no ._start name in the disassembly >> listed by objdump. >>=20 >> By contrast for -fuse-ld=3Dbfd building a.out objdump shows: >>=20 >> 0000000010000438 <._start> mflr r0 >> 000000001000043c <._start+0x4> mfcr r12 >> 0000000010000440 <._start+0x8> std r31,-8(r1) >> 0000000010000444 <._start+0xc> std r0,16(r1) >> 0000000010000448 <._start+0x10> stw r12,8(r1) >> 000000001000044c <._start+0x14> stdu r1,-176(r1) >> . . . >>=20 >>=20 >> In gdb for ld.lld used: >>=20 >> Reading symbols from a.out...done. >> (gdb) br *0x00000000500279ac >> Breakpoint 1 at 0x500279ac >> (gdb) run >> Starting program: /root/c_tests/a.out=20 >>=20 >> Breakpoint 1, ._rtld_start () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 >> 104 blrl /* _start(argc, argv, envp, obj, cleanup, = ps_strings) */ >> (gdb) stepi >> 0x0000000010010000 in ?? () >> (gdb)=20 >> 0x0000000010010004 in ?? () >> (gdb) display/i $pc >> 1: x/i $pc >> =3D> 0x10010004: mfcr r12 >> (gdb) stepi >> 0x0000000010010008 in ?? () >> 1: x/i $pc >> =3D> 0x10010008: std r31,-8(r1) >> (gdb)=20 >> 0x000000001001000c in ?? () >> 1: x/i $pc >> =3D> 0x1001000c: std r0,16(r1) >>=20 >> . . . >>=20 >> (gdb)=20 >> 0x00000000100100a0 in ?? () >> 1: x/i $pc >> =3D> 0x100100a0: beq 0x100100ac >> (gdb)=20 >> 0x00000000100100ac in ?? () >> 1: x/i $pc >> =3D> 0x100100ac: cmpldi r8,0 >> (gdb)=20 >> 0x00000000100100b0 in ?? () >> 1: x/i $pc >> =3D> 0x100100b0: beq 0x100100c0 >> (gdb)=20 >> 0x00000000100100c0 in ?? () >> 1: x/i $pc >> =3D> 0x100100c0: addis r3,r2,0 >> (gdb)=20 >> 0x00000000100100c4 in ?? () >> 1: x/i $pc >> =3D> 0x100100c4: ld r3,32552(r3) >> (gdb)=20 >> 0x00000000100100c8 in ?? () >> 1: x/i $pc >> =3D> 0x100100c8: cmpldi r3,0 >> (gdb)=20 >> 0x00000000100100cc in ?? () >> 1: x/i $pc >> =3D> 0x100100cc: beq 0x100100e0 >> (gdb)=20 >> 0x00000000100100d0 in ?? () >> 1: x/i $pc >> =3D> 0x100100d0: mr r3,r7 >> (gdb)=20 >> 0x00000000100100d4 in ?? () >> 1: x/i $pc >> =3D> 0x100100d4: bl 0x10010560 >>=20 >> Note: Below is from plt : >>=20 >> Disassembly of section .plt: >> 0000000010010560 <.plt> std r2,40(r1) >> 0000000010010564 <.plt+0x4> addis r11,r2,0 >> 0000000010010568 <.plt+0x8> ld r12,32512(r11) >> 000000001001056c <.plt+0xc> ld r11,0(r12) <<<<<=3D=3D=3D=3D=3D = Fails here. >> 0000000010010570 <.plt+0x10> mtctr r11 >> 0000000010010574 <.plt+0x14> ld r2,8(r12) >> 0000000010010578 <.plt+0x18> ld r11,16(r12) >> 000000001001057c <.plt+0x1c> bctr >>=20 >> (By setting breakpoints in the 3 such .plt code blocks: >> this is the first .plt code block executed and it fails.) >>=20 >> The .plt is different from what ld.bfd generates: >> no __glink_PLTresolve or its use and the code does >> not appear strictly equivalent to me. >>=20 >> Back to gdb based information: >>=20 >> (gdb) info registers >> r0 0x500279b0 1342339504 >> r1 0xffffffffffffda40 18446744073709541952 >> r2 0x10028138 268599608 >> r3 0x50058b30 1342540592 >> r4 0x0 0 >> r5 0xffffffffffffdbc8 18446744073709542344 >> r6 0x5004c000 1342488576 >> r7 0x50058b30 1342540592 >> r8 0x0 0 >> r9 0x0 0 >> r10 0x0 0 >> r11 0x0 0 >> r12 0x22000c00 570428416 >> r13 0x50057010 1342533648 >> r14 0x0 0 >> r15 0x0 0 >> r16 0x0 0 >> r17 0x0 0 >> r18 0x0 0 >> r19 0x0 0 >> r20 0x0 0 >> r21 0x0 0 >> r22 0x0 0 >> r23 0x0 0 >> r24 0x0 0 >> r25 0x10028138 268599608 >> r26 0x0 0 >> r27 0x0 0 >> r28 0x1 1 >> r29 0xffffffffffffdbb8 18446744073709542328 >> r30 0xffffffffffffdbc8 18446744073709542344 >> r31 0xffffffffffffda40 18446744073709541952 >> pc 0x10010560 0x10010560 >> msr >> cr 0x42000c00 1107299328 >> lr 0x100100d8 0x100100d8 >> ctr 0x50043a80 1342454400 >> xer 0x20000000 536870912 >>=20 >> (gdb)=20 >> 0x0000000010010560 in ?? () >> 1: x/i $pc >> =3D> 0x10010560: std r2,40(r1) >> (gdb)=20 >> 0x0000000010010564 in ?? () >> 1: x/i $pc >> =3D> 0x10010564: addis r11,r2,0 >> (gdb)=20 >> 0x0000000010010568 in ?? () >> 1: x/i $pc >> =3D> 0x10010568: ld r12,32512(r11) >> (gdb)=20 >> 0x000000001001056c in ?? () >> 1: x/i $pc >> =3D> 0x1001056c: ld r11,0(r12) >> (gdb)=20 >>=20 >> Program received signal SIGSEGV, Segmentation fault. >> 0x000000001001056c in ?? () >> 1: x/i $pc >> =3D> 0x1001056c: ld r11,0(r12) >>=20 >> The source code (from lib/csu/powerpc64/crt1.c ) is: >>=20 >> void >> _start(int argc, char **argv, char **env, >> const struct Struct_Obj_Entry *obj __unused, void (*cleanup)(void), >> struct ps_strings *ps_strings) >> { >>=20 >> handle_argv(argc, argv, env); >>=20 >> if (ps_strings !=3D (struct ps_strings *)0) >> __ps_strings =3D ps_strings; >>=20 >> if (&_DYNAMIC !=3D NULL) >> atexit(cleanup); >> else >> _init_tls(); >>=20 >> #ifdef GCRT >> atexit(_mcleanup); >> monstartup(&eprol, &etext); >> #endif >>=20 >> handle_static_init(argc, argv, env); >> exit(main(argc, argv, env)); >> } >>=20 >> The 3 plt code blocks are for: >>=20 >> atexit >> _init_tls >> exit >>=20 >> from what I can tell, possibly not in that order. >>=20 >> Overall: The plt handling seems to be broken. >>=20 >>=20 >>> You can also build rtld with additional debugging by adding -DDEBUG = to >>> CFLAGS. In libexec/rtld-elf/Makefile there's an example command line >>> for building it locally, but I've just added CFLAGS+=3D-DDEBUG to = the >>> Makefile in my test tree and built it along with the rest of my full >>> cross build. >>=20 >> # svnlite diff /usr/src/libexec/rtld-elf/Makefile >> Index: /usr/src/libexec/rtld-elf/Makefile >> =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 >> --- /usr/src/libexec/rtld-elf/Makefile (revision 311950) >> +++ /usr/src/libexec/rtld-elf/Makefile (working copy) >> @@ -17,6 +17,7 @@ >> malloc.c xmalloc.c debug.c libmap.c >> MAN=3D rtld.1 >> CSTD?=3D gnu99 >> +CFLAGS+=3D-DDEBUG >> CFLAGS+=3D -Wall -DFREEBSD_ELF -DIN_RTLD -ffreestanding >> CFLAGS+=3D -I${SRCTOP}/lib/csu/common >> .if exists(${.CURDIR}/${MACHINE_ARCH}) >>=20 >> The above did not seem to make much of a difference for the >> code involved, likely because crt1.c is from >> lib/csu/powerpc64/ instead of from libexec/rtld-elf/ . >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org"