From owner-freebsd-ppc@freebsd.org Sat Jan 21 20:19:30 2017 Return-Path: Delivered-To: freebsd-ppc@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 C7921CBB431 for ; Sat, 21 Jan 2017 20:19:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-11.reflexion.net [208.70.210.11]) (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 8C718942 for ; Sat, 21 Jan 2017 20:19:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2117 invoked from network); 21 Jan 2017 20:19:23 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 21 Jan 2017 20:19:23 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Sat, 21 Jan 2017 15:19:23 -0500 (EST) Received: (qmail 17572 invoked from network); 21 Jan 2017 20:19:23 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 21 Jan 2017 20:19: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 75150EC8257; Sat, 21 Jan 2017 12:19:22 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: I have submitted llvm bugzilla 31716 for lld 3.9.1's incoherent .plt vs. .got.plt content for powerpc64 Message-Id: Date: Sat, 21 Jan 2017 12:19:21 -0800 Cc: Roman Divacky , Justin Hibbits , Nathan Whitehorn To: Ed Maste , FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 20:19:30 -0000 I've copied the submittal information later below. I've also added 31716 to llvm bugzilla 25780 (the meta-submittal for using clang as the FreeBSD/ppc system context). If this is wrong for some reason fell free to delete the item from the Depends On list. I did reference: > I've not found any powerpc family documentation > for .got.plt use: No such powerpc64 ABI yet? What I wrote in the submittal was: > powerpc64 context for: >=20 > # more main.c > static volatile char big_area[67001] =3D "This is a test"; >=20 > int main () > { > big_area[67000] =3D '9'; > } >=20 > via: >=20 > clang -fuse-ld=3Dlld -g main.c >=20 > The code that is put in the .plt that does not > match the .got.plt layout used (expecting function > descriptors when there are only single addresses per > function as a .got.plt entry) is: >=20 > void PPC64TargetInfo::writePlt(uint8_t *Buf, uint64_t GotEntryAddr, > uint64_t PltEntryAddr, int32_t Index, > unsigned RelOff) const { > uint64_t Off =3D GotEntryAddr - getPPC64TocBase(); >=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 > write32be(Buf, 0xf8410028); // std %r2, 40(%r1) > write32be(Buf + 4, 0x3d620000 | applyPPCHa(Off)); // addis %r11, %r2, = X@ha > write32be(Buf + 8, 0xe98b0000 | applyPPCLo(Off)); // ld %r12, = X@l(%r11) > write32be(Buf + 12, 0xe96c0000); // ld %r11,0(%r12) > write32be(Buf + 16, 0x7d6903a6); // mtctr %r11 > write32be(Buf + 20, 0xe84c0008); // ld %r2,8(%r12) > write32be(Buf + 24, 0xe96c0010); // ld %r11,16(%r12) > write32be(Buf + 28, 0x4e800420); // bctr > } >=20 > But what ld.lld generated for relocation was: >=20 > Relocation section with addend (.rela.plt): > r_offset r_info r_type st_value st_name = + r_addend > 000010030038 000300000015 R_PPC64_JMP_SLOT 0000000000000000 atexit = + 0 > 000010030040 000200000015 R_PPC64_JMP_SLOT 0000000000000000 = _init_tls + 0 > 000010030048 000500000015 R_PPC64_JMP_SLOT 0000000000000000 exit + = 0 >=20 > These r_offset's are in the .got.plt area, not in the .plt area: >=20 > 0x0000000010030020 - 0x0000000010030050 is .got.plt >=20 > The increment is 0x8 between entries, not 0x18 (or more) that > would be needed for function descriptors: There is no > function descriptor space here. >=20 > It looks like the other side of this that is not establishing > space for function descriptors is in the code in: >=20 > /usr/src/contrib/llvm/tools/lld/ELF/Relocations.cpp >=20 > in its scanRelocs : >=20 > // At this point we are done with the relocated position. Some = relocations > // also require us to create a got or plt entry. >=20 > // If a relocation needs PLT, we create a PLT and a GOT slot for = the symbol. > if (needsPlt(Expr)) { > if (Body.isInPlt()) > continue; > Out::Plt->addEntry(Body); >=20 > uint32_t Rel; > if (Body.isGnuIFunc() && !Preemptible) > Rel =3D Target->IRelativeRel; > else > Rel =3D Target->PltRel; >=20 > Out::GotPlt->addEntry(Body); > Out::RelaPlt->addReloc({Rel, Out::GotPlt, > Body.getGotPltOffset(), = !Preemptible, > &Body, 0}); > continue; > } >=20 > The code is explicitly targeting creating GotPlt space, not > .opd space, as well., not matching the earlier comment in > PPC64TargetInfo::writePlt . >=20 > The effect of such code and the wrtPlt code need to be > correctly matching but currently are not. >=20 > For ld.lld's a.out its .plt (not .got.plt) is code, > unlike in the ld.bfd generated a.out: >=20 > Disassembly of section .plt: > 0000000010010550 <.plt> std r2,40(r1) > 0000000010010554 <.plt+0x4> addis r11,r2,0 > 0000000010010558 <.plt+0x8> ld r12,32512(r11) Note: = r12=3D=3D0x000010030038 results > 000000001001055c <.plt+0xc> ld r11,0(r12) > 0000000010010560 <.plt+0x10> mtctr r11 > 0000000010010564 <.plt+0x14> ld r2,8(r12) Note: accesses = 0x000010030040 see .plt+0x28 > 0000000010010568 <.plt+0x18> ld r11,16(r12) Note: accesses = 0x000010030048 see .plt+0x48 > 000000001001056c <.plt+0x1c> bctr >=20 > Note: The code expects 0(12), 8(12), and 16(r12) storage > but not such structure is present: 8(r12) above is > equivalent to 0(r12) below as an example. >=20 > 0000000010010570 <.plt+0x20> std r2,40(r1) > 0000000010010574 <.plt+0x24> addis r11,r2,0 > 0000000010010578 <.plt+0x28> ld r12,32520(r11) Note: = r12=3D=3D0x000010030040 results > 000000001001057c <.plt+0x2c> ld r11,0(r12) > 0000000010010580 <.plt+0x30> mtctr r11 > 0000000010010584 <.plt+0x34> ld r2,8(r12) Note: accesses = 0x000010030048 see .plt+0x48 > 0000000010010588 <.plt+0x38> ld r11,16(r12) Note: accesses = 0x000010030050 > 000000001001058c <.plt+0x3c> bctr >=20 > Note: 0x000010030050 is from: >=20 > 0x0000000010030050 - 0x00000000100300a0 is .toc >=20 > 0000000010010590 <.plt+0x40> std r2,40(r1) > 0000000010010594 <.plt+0x44> addis r11,r2,0 > 0000000010010598 <.plt+0x48> ld r12,32528(r11) Note: = r12=3D=3D0x000010030048 results > 000000001001059c <.plt+0x4c> ld r11,0(r12) > 00000000100105a0 <.plt+0x50> mtctr r11 > 00000000100105a4 <.plt+0x54> ld r2,8(r12) Note: accesses = 0x000010030050 > 00000000100105a8 <.plt+0x58> ld r11,16(r12) Note: accesses = 0x000010030058 > 00000000100105ac <.plt+0x5c> bctr >=20 > Note: 0x000010030050 and 0x000010030058 are from: >=20 > 0x0000000010030050 - 0x00000000100300a0 is .toc >=20 > Either the .got.plt entry layout changes to have room > for 8(r12) and 16(r12) positions (size change to 0x18 > Bytes per entry) or this code (and possibly other > code) changes --presuming .got.plt style is used at > all. (I've not found any powerpc family documentation > for .got.plt use: No such powerpc64 ABI yet?) >=20 > By contrast the -fuse-ld=3Dbfd ends up with: >=20 > Relocation section with addend (.rela.plt): > r_offset r_info r_type st_value st_name = + r_addend > 0000100218b0 000300000015 R_PPC64_JMP_SLOT 0000000000000000 atexit = + 0 > 0000100218c8 000400000015 R_PPC64_JMP_SLOT 0000000000000000 = _init_tls + 0 > 0000100218e0 000600000015 R_PPC64_JMP_SLOT 0000000000000000 exit + = 0 >=20 > is an increment of 0x18 between entries (room for the > function descriptors). The r_offset's are from the > ld.bfd generated .plt section: >=20 > 0x0000000010021898 - 0x00000000100218f8 is .plt >=20 > NOTE: For the FreeBSD ld.bfd context the .plt does not have > blocks of code for such, just the function descriptors. =3D=3D=3D Mark Millard markmi at dsl-only.net