From owner-freebsd-toolchain@freebsd.org Tue Jan 17 21:53:22 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 23636CB405F for ; Tue, 17 Jan 2017 21:53:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-17.reflexion.net [208.70.210.17]) (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 DAB98163A for ; Tue, 17 Jan 2017 21:53:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17162 invoked from network); 17 Jan 2017 21:54:47 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 17 Jan 2017 21:54:47 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Tue, 17 Jan 2017 16:53:15 -0500 (EST) Received: (qmail 388 invoked from network); 17 Jan 2017 21:53:15 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 17 Jan 2017 21:53:15 -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 D6445EC7B46; Tue, 17 Jan 2017 13:53:14 -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: <20170117195424.GA89237@vlakno.cz> Date: Tue, 17 Jan 2017 13:53:14 -0800 Cc: Ed Maste , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <237EB920-0795-4B18-94D4-2EAC0FC76F01@dsl-only.net> References: <20170112192223.GA49469@vlakno.cz> <932E3C38-B226-4BF1-B587-5A2D5EA19300@dsl-only.net> <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> <27422F1B-6906-4D37-860A-D1BC8DC83BBF@dsl-only.net> <20170117195424.GA89237@vlakno.cz> To: Roman Divacky 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: Tue, 17 Jan 2017 21:53:22 -0000 On 2017-Jan-17, at 11:54 AM, Roman Divacky = wrote: . . . > 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::Got->getVA(); > + uint64_t TocVA =3D In::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 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): 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::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; } [Also the "// TOC . . ." comment is at line 1005 (given the prior GotRel vs. PltRel split into separate lines).] Which should I use?: In vs. Out > would make any difference? It's not correct but might shed some light = on what needs to be done > if I am right. 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: 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!!!! Is that expected/desired/allowed? > Could you explore this please? After you report for sure for In vs. Out I'll take a stab at it. =3D=3D=3D Mark Millard markmi at dsl-only.net