From owner-freebsd-toolchain@freebsd.org Sun Jan 15 06:53:24 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 47C91CB182F for ; Sun, 15 Jan 2017 06:53:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 F16D41C6B for ; Sun, 15 Jan 2017 06:53:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 915 invoked from network); 15 Jan 2017 06:53:41 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 15 Jan 2017 06:53:41 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Sun, 15 Jan 2017 01:53:16 -0500 (EST) Received: (qmail 13548 invoked from network); 15 Jan 2017 06:53:16 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Jan 2017 06:53:16 -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 783BDEC8A88; Sat, 14 Jan 2017 22:53:15 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: qemu-arm-static appears to have problems with signal delivery during (at least) poudrirer-devel based cross builds of some ports with ALLOW_MAKE_JOBS=yes Message-Id: Date: Sat, 14 Jan 2017 22:53:14 -0800 To: freebsd-arm , FreeBSD Toolchain 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: Sun, 15 Jan 2017 06:53:24 -0000 [Context: head (12) -r312009 and ports head -r431413.] I've been experimenting on amd64 with poudriere-devel with -x for -a arm.armv6 and I ran into: > TCG temporary leak before 00021826 > qemu: uncaught target signal 4 (Illegal instruction) - core dumped in 3 of the 31 ports for the build, but 4 skipped so 3 of 27 attempted. The 00021826 is the same number in all the examples so far (whatever its base). These seem to be the only TCG messages and each failure starts with one and then reports the qemu message. (Also true for the below.) As far as I can tell the TCG notice is the report of an internal qemu problem that is then translated into an Illegal instruction. This was with ALLOW_MAKE_JOBS=yes but -J 1 for poudriere. For 2 of the problem ports retries worked, still using ALLOW_MAKE_JOBS=yes and -J 1 . But the 3rd port failed each time tried with ALLOW_MAKE_JOBS=yes --but in a different step each time. In all failure cases it was gmake that got the "illegal instruction". But disabling ALLOW_MAKE_JOBS=yes appears (so far) to avoid the issue. For example, that 3rd failing port built fine. (I've been doing more ports since, with ALLOW_MAKE_JOBS=yes repeatedly failing and lack of it working.) My guess is SIGCHLD delivery sometimes touches something (or a timing) that is not handled well in qemu-arm-static. I've had not problems on an rpi2 or bpim3 in the past. (I have seen some analogous "soemtimes" issues on powerpc under and version of lang that mishandled the stack part of the ABI FreeBSD uses, SIGCHLD sometimes getting on the stack at a bad-time for the messed up code generation, leading to stack corruption. Code not getting signals had no problems.) Note: The amd64 context is FreeBSD under VirtualBox under macOS and it has had no problem for native builds of world, kernel, or ports. === Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Jan 15 08:51:37 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 14652CB17AE for ; Sun, 15 Jan 2017 08:51:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 DE1751D65 for ; Sun, 15 Jan 2017 08:51:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0F8parR024898 for ; Sun, 15 Jan 2017 08:51:36 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216080] science/bddsolve: fails to build with libc++ 4.0 Date: Sun, 15 Jan 2017 08:51:37 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ed@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sun, 15 Jan 2017 08:51:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216080 Jan Beich (mail not working) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |freebsd-toolchain@FreeBSD.o | |rg --- Comment #3 from Jan Beich (mail not working) --- > bool exists_file(const std::string& filename) > { > std::ifstream from(filename.c_str()); > - return (from); > + return !from.fail(); Why not "return from.good()" instead similar to textproc/libxml++26 upstream fix? Otherwise, ask toolchain@ whether to convert or not. I don't know much C++. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Jan 15 08:54:05 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 CB701CB1831 for ; Sun, 15 Jan 2017 08:54:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 BAE7D1F53 for ; Sun, 15 Jan 2017 08:54:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0F8s5Kt034644 for ; Sun, 15 Jan 2017 08:54:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216080] science/bddsolve: fails to build with libc++ 4.0 Date: Sun, 15 Jan 2017 08:54:06 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ed@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ed@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sun, 15 Jan 2017 08:54:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216080 --- Comment #4 from Ed Schouten --- Because the good() member function isn't the exact opposite of the fail() member function. See the table at the bottom of this page: http://en.cppreference.com/w/cpp/io/basic_ios/fail Changing it to use good() alters the code's behaviour. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Jan 15 14:09:23 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 2054ACB16D5 for ; Sun, 15 Jan 2017 14:09:23 +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 DAC251EF9 for ; Sun, 15 Jan 2017 14:09:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29980 invoked from network); 15 Jan 2017 14:09:16 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 15 Jan 2017 14:09:16 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Sun, 15 Jan 2017 09:09:16 -0500 (EST) Received: (qmail 30581 invoked from network); 15 Jan 2017 14:09:15 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Jan 2017 14:09: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 270CDEC7B11; Sun, 15 Jan 2017 06:09:15 -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: Re: qemu-arm-static appears to have problems with signal delivery during (at least) poudrirer-devel based cross builds of some ports with ALLOW_MAKE_JOBS=yes Date: Sun, 15 Jan 2017 06:09:14 -0800 References: To: freebsd-arm , FreeBSD Toolchain In-Reply-To: Message-Id: <7AF92A3C-3563-4B2E-B14A-D6BAF30A16A2@dsl-only.net> 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: Sun, 15 Jan 2017 14:09:23 -0000 On 2017-Jan-14, at 10:53 PM, Mark Millard = wrote: > [Context: head (12) -r312009 and ports head -r431413.] >=20 > I've been experimenting on amd64 with poudriere-devel with -x > for -a arm.armv6 and I ran into: >=20 >> TCG temporary leak before 00021826 >> qemu: uncaught target signal 4 (Illegal instruction) - core dumped >=20 > in 3 of the 31 ports for the build, but 4 skipped so 3 of 27 > attempted. The 00021826 is the same number in all the examples > so far (whatever its base). >=20 > These seem to be the only TCG messages and each failure starts with > one and then reports the qemu message. (Also true for the below.) > As far as I can tell the TCG notice is the report of an internal > qemu problem that is then translated into an Illegal instruction. >=20 > This was with ALLOW_MAKE_JOBS=3Dyes but -J 1 for poudriere. >=20 > For 2 of the problem ports retries worked, still using > ALLOW_MAKE_JOBS=3Dyes and -J 1 . >=20 > But the 3rd port failed each time tried with ALLOW_MAKE_JOBS=3Dyes > --but in a different step each time. >=20 > In all failure cases it was gmake that got the "illegal instruction". >=20 > But disabling ALLOW_MAKE_JOBS=3Dyes appears (so far) to avoid the > issue. For example, that 3rd failing port built fine. (I've > been doing more ports since, with ALLOW_MAKE_JOBS=3Dyes repeatedly > failing and lack of it working.) >=20 > My guess is SIGCHLD delivery sometimes touches something (or a timing) > that is not handled well in qemu-arm-static. I've had not problems > on an rpi2 or bpim3 in the past. >=20 > (I have seen some analogous "soemtimes" issues on powerpc under > and version of lang that mishandled the stack part of the ABI > FreeBSD uses, SIGCHLD sometimes getting on the stack at a bad-time > for the messed up code generation, leading to stack corruption. Code > not getting signals had no problems.) >=20 > Note: The amd64 context is FreeBSD under VirtualBox under macOS > and it has had no problem for native builds of world, kernel, > or ports. Avoiding ALLOW_MAKE_JOBS=3Dyes is not sufficient to guarantee builds will work. Here is one that got near the end before failing the same way: . . . install -m 0644 = /wrkdirs/usr/ports/devel/arm-none-eabi-gcc/work/gcc-6.3.0/gcc/cp/type-util= s.h = /wrkdirs/usr/ports/devel/arm-none-eabi-gcc/work/stage/usr/local/lib/gcc/ar= m-none-eabi/6.3.0/plugin/include/cp/type-utils.h install: DONTSTRIP set - will not strip installed binaries TCG temporary leak before 00021826 qemu: uncaught target signal 4 (Illegal instruction) - core dumped gmake[1]: *** [Makefile:4176: install-gcc] Illegal instruction gmake[1]: Leaving directory = '/wrkdirs/usr/ports/devel/arm-none-eabi-gcc/work/.build' *** Error code 2 Stop. make: stopped in /usr/ports/devel/arm-none-eabi-gcc =3D=3D=3D=3D>> Cleaning up wrkdir =3D=3D=3D> Cleaning for arm-none-eabi-gcc-6.3.0 build of devel/arm-none-eabi-gcc ended at Sun Jan 15 00:04:02 PST 2017 build time: 02:52:28 !!! build failure encountered !!! Going back to the earlier initial problem (that I happen to have the material for handy): expanding the .tbz of the failed build and finding the core showed: # find . -name "*.core" -exec file {} \; = = = = ./work/binutils-2.27/ld/qemu_gmake.core: ELF 32-bit LSB core file ARM, = version 1 (FreeBSD), FreeBSD-style, from 'ke' [I've not figured out what I can do with that --or how.] One thing unusual on my part is that I use -mcpu=3Dcortex-a7 . That matches how I historically buildworld buildkernel for installation on the rpi2 and bpim3. I've never had problems like this with builds on the rpi2 or the bpim3 (buildworld, buildkernel, port builds). It might be that qemu-arm-static has a problem with -mcpu=3Dcortex-a7 code that is generated --but not always. Using the make.conf as an example: # more /usr/local/etc/poudriere.d/head-cortex-a7-make.conf WANT_QT_VERBOSE_CONFIGURE=3D1 # DEFAULT_VERSIONS+=3Dperl5=3D5.24 WITH_DEBUG=3D WITH_DEBUG_FILES=3D MALLOC_PRODUCTION=3D # #system clang 3.8+ (gcc6 rejects -march=3Darmv7a): #CFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 #CXXFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 #CPPFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 # #lang/gcc6's xgcc stage considers the above conflicting so use just: CFLAGS+=3D -mcpu=3Dcortex-a7 CXXFLAGS+=3D -mcpu=3Dcortex-a7 CPPFLAGS+=3D -mcpu=3Dcortex-a7 For my context poudriere with -x for -a arm.armv6 and the use of qemu-arm-static does not look reliable enough to depend on. It is not obvious that the -x use contributes to the problem: it may well not. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Jan 15 16:42:56 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 76B6ECAFA5B for ; Sun, 15 Jan 2017 16:42:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 65D961E39 for ; Sun, 15 Jan 2017 16:42:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0FGgtGY005286 for ; Sun, 15 Jan 2017 16:42:56 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216117] devel/llvm39: clang crashes trying to build lld on i386 Date: Sun, 15 Jan 2017 16:42:56 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: version product flagtypes.name assigned_to component Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sun, 15 Jan 2017 16:42:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216117 Jan Beich (mail not working) changed: What |Removed |Added ---------------------------------------------------------------------------- Version|Latest |CURRENT Product|Ports & Packages |Base System Flags|maintainer-feedback?(brooks | |@FreeBSD.org) | Assignee|brooks@FreeBSD.org |freebsd-toolchain@FreeBSD.o | |rg Component|Individual Port(s) |bin --- Comment #1 from Jan Beich (mail not working) --- Oops, this is for /projects/clang400-import@312229. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Jan 15 16:44:29 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 359D9CAFAC1 for ; Sun, 15 Jan 2017 16:44:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 250E11EAC for ; Sun, 15 Jan 2017 16:44:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0FGiTAB008968 for ; Sun, 15 Jan 2017 16:44:29 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216117] devel/llvm39: clang crashes trying to build lld on i386 Date: Sun, 15 Jan 2017 16:44:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sun, 15 Jan 2017 16:44:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216117 --- Comment #2 from Jan Beich (mail not working) --- Created attachment 178923 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D178923&action= =3Dedit OutputSections-8d5025.cpp (compressed) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Jan 15 16:45:06 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 C9BFDCAFAEF for ; Sun, 15 Jan 2017 16:45:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 B944B1ED6 for ; Sun, 15 Jan 2017 16:45:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0FGj6jb010499 for ; Sun, 15 Jan 2017 16:45:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216117] devel/llvm39: clang crashes trying to build lld on i386 Date: Sun, 15 Jan 2017 16:45:06 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sun, 15 Jan 2017 16:45:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216117 --- Comment #3 from Jan Beich (mail not working) --- Created attachment 178924 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D178924&action= =3Dedit OutputSections-8d5025.sh --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Jan 15 16:45:24 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 0B904CAFB27 for ; Sun, 15 Jan 2017 16:45:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 EF4F81EF9 for ; Sun, 15 Jan 2017 16:45:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0FGjNnN011382 for ; Sun, 15 Jan 2017 16:45:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216117] devel/llvm39: clang crashes trying to build lld on i386 Date: Sun, 15 Jan 2017 16:45:24 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.mimetype Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sun, 15 Jan 2017 16:45:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216117 Jan Beich (mail not working) changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #178924|application/x-shellscript |text/plain mime type| | --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Jan 15 17:13:01 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 17549CB1ADF for ; Sun, 15 Jan 2017 17:13:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 06FFC1326 for ; Sun, 15 Jan 2017 17:13:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0FHD0N7007765 for ; Sun, 15 Jan 2017 17:13:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216117] clang 4.0.0 crashes trying to build lld on i386 Date: Sun, 15 Jan 2017 17:13:01 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: emaste@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sun, 15 Jan 2017 17:13:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216117 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emaste@freebsd.org Summary|devel/llvm39: clang crashes |clang 4.0.0 crashes trying |trying to build lld on i386 |to build lld on i386 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Jan 15 18:34:16 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 0611ECB18B2 for ; Sun, 15 Jan 2017 18:34:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 E952119FA for ; Sun, 15 Jan 2017 18:34:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0FIYFER068258 for ; Sun, 15 Jan 2017 18:34:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216117] clang 4.0.0 crashes trying to build lld on i386 Date: Sun, 15 Jan 2017 18:34:16 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sun, 15 Jan 2017 18:34:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216117 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dim@FreeBSD.org --- Comment #4 from Dimitry Andric --- Hm, yes, I'm seeing this too, while building llvm38 even. Something is rot= ten, but it's hard to figure out what. For some reason, a cleanly built release= _40 r292009 on universe12a.f.o works fine, but on my local system, it doesn't. I'm trying valgrind to figure out what is going wrong, and it gives me: =3D=3D1793=3D=3D Invalid read of size 8 =3D=3D1793=3D=3D at 0x227C9BE: llvm::ValueHandleBase::AddToUseList() (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/= clang/clang.full) =3D=3D1793=3D=3D by 0x29A3F2D: llvm::AssumptionCache::AffectedValueCallbackVH::allUsesReplacedWith(llvm::V= alue*) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/= clang/clang.full) =3D=3D1793=3D=3D by 0x227A884: llvm::ValueHandleBase::ValueIsRAUWd(llvm:= :Value*, llvm::Value*) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/= clang/clang.full) =3D=3D1793=3D=3D by 0x227A504: llvm::Value::doRAUW(llvm::Value*, bool) (= in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/= clang/clang.full) =3D=3D1793=3D=3D by 0x1C9791E: llvm::sroa::AllocaSliceRewriter::visitLoadInst(llvm::LoadInst&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/= clang/clang.full) =3D=3D1793=3D=3D by 0x1C880FD: llvm::sroa::AllocaSliceRewriter::visit((a= nonymous namespace)::Slice const*) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/= clang/clang.full) =3D=3D1793=3D=3D by 0x1C86C9A: llvm::SROA::rewritePartition(llvm::Alloca= Inst&, llvm::sroa::AllocaSlices&, llvm::sroa::Partition&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/= clang/clang.full) =3D=3D1793=3D=3D by 0x1C88584: llvm::SROA::splitAlloca(llvm::AllocaInst&, llvm::sroa::AllocaSlices&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/= clang/clang.full) =3D=3D1793=3D=3D by 0x1C89A1D: llvm::SROA::runOnAlloca(llvm::AllocaInst&= ) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/= clang/clang.full) =3D=3D1793=3D=3D by 0x1C8B309: llvm::SROA::runImpl(llvm::Function&, llvm::DominatorTree&, llvm::AssumptionCache&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/= clang/clang.full) =3D=3D1793=3D=3D by 0x1C9C239: llvm::sroa::SROALegacyPass::runOnFunction(llvm::Function&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/= clang/clang.full) =3D=3D1793=3D=3D by 0x22B78D9: llvm::FPPassManager::runOnFunction(llvm::= Function&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/= clang/clang.full) =3D=3D1793=3D=3D Address 0x5a5a5a5a5a5a5a62 is not stack'd, malloc'd or (r= ecently) free'd =3D=3D1793=3D=3D pid 1793 (memcheck-amd64-free): sigreturn rflags =3D 0x4 =3D=3D1793=3D=3D =3D=3D1793=3D=3D Process terminating with default action of signal 10 (SIGB= US): dumping core =3D=3D1793=3D=3D Hardware error at address 0x40F7A495F =3D=3D1793=3D=3D at 0x227C9BE: llvm::ValueHandleBase::AddToUseList() (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/= clang/clang.full) =3D=3D1793=3D=3D by 0x29A3F2D: llvm::AssumptionCache::AffectedValueCallbackVH::allUsesReplacedWith(llvm::V= alue*) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/= clang/clang.full) =3D=3D1793=3D=3D by 0x227A884: llvm::ValueHandleBase::ValueIsRAUWd(llvm:= :Value*, llvm::Value*) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/= clang/clang.full) =3D=3D1793=3D=3D by 0x227A504: llvm::Value::doRAUW(llvm::Value*, bool) (= in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/= clang/clang.full) =3D=3D1793=3D=3D by 0x1C9791E: llvm::sroa::AllocaSliceRewriter::visitLoadInst(llvm::LoadInst&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/= clang/clang.full) =3D=3D1793=3D=3D by 0x1C880FD: llvm::sroa::AllocaSliceRewriter::visit((a= nonymous namespace)::Slice const*) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/= clang/clang.full) =3D=3D1793=3D=3D by 0x1C86C9A: llvm::SROA::rewritePartition(llvm::Alloca= Inst&, llvm::sroa::AllocaSlices&, llvm::sroa::Partition&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/= clang/clang.full) =3D=3D1793=3D=3D by 0x1C88584: llvm::SROA::splitAlloca(llvm::AllocaInst&, llvm::sroa::AllocaSlices&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/= clang/clang.full) =3D=3D1793=3D=3D by 0x1C89A1D: llvm::SROA::runOnAlloca(llvm::AllocaInst&= ) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/= clang/clang.full) =3D=3D1793=3D=3D by 0x1C8B309: llvm::SROA::runImpl(llvm::Function&, llvm::DominatorTree&, llvm::AssumptionCache&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/= clang/clang.full) =3D=3D1793=3D=3D by 0x1C9C239: llvm::sroa::SROALegacyPass::runOnFunction(llvm::Function&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/= clang/clang.full) =3D=3D1793=3D=3D by 0x22B78D9: llvm::FPPassManager::runOnFunction(llvm::= Function&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/= clang/clang.full) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Jan 15 23:03:41 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 12AB2CB1EBB for ; Sun, 15 Jan 2017 23:03:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 0222F16E9 for ; Sun, 15 Jan 2017 23:03:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0FN3eBZ032672 for ; Sun, 15 Jan 2017 23:03:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216117] clang 4.0.0 crashes trying to build lld on i386 Date: Sun, 15 Jan 2017 23:03:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sun, 15 Jan 2017 23:03:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216117 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress --- Comment #5 from Dimitry Andric --- I managed to figure out that upstream https://reviews.llvm.org/rL291671 cau= sed a use-after-free issue, which is why it doesn't always crash. I had to run= it under valgrind to see relatively clearly where it came from. Hal Finkel has put up a review for a fix here: https://reviews.llvm.org/D28= 749 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Jan 16 19:43:12 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 4D369CB3411 for ; Mon, 16 Jan 2017 19:43:12 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id C3DE91366; Mon, 16 Jan 2017 19:43:10 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id 2CB3C12CCC9; Mon, 16 Jan 2017 20:40:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1484595635; bh=Nk8NQg1fkT2R3U7i7ChgRdV2Q72Y9eXNOZya47k3a3A=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=Cs8jQX6WqfRy2vvZcuEr1JgMvAbRk0bBqs0rY4lNHLfUopOxWajgLeULyP3nd9KTV pVSrSbAWJFmMcmV72MWMa2/7yFRWxOqrSGBbeoaM+DNJLgKVkD+KQJ3HGOpi6ZgZT/ pwObkIVgwcbSDA9wGhf68emVXV+sppNcHuBMOgPk= Date: Mon, 16 Jan 2017 20:40:35 +0100 From: Roman Divacky To: Mark Millard Cc: Ed Maste , FreeBSD Toolchain 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: <20170116194035.GA20175@vlakno.cz> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) 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 19:43:12 -0000 Mark, I think the TOC (.got + .plt) has to be contiguous in memory. The on-disk layout is not that important. Can you check whats the difference of the in-memory TOC between lld and ld.bfd? Thanks, Roman On Fri, Jan 13, 2017 at 02:07:00PM -0800, Mark Millard wrote: > Just an FYI: > > elfdump -a (from -r311950) does not dump .plt or .got.plt or .toc : > > # 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): > > (The "global offset table" was empty but its title was listed.) > > === > Mark Millard > markmi at dsl-only.net > > On 2017-Jan-12, at 5:58 PM, Mark Millard wrote: > > On 2017-Jan-12, at 11:22 AM, Roman Divacky wrote: > > > Can you check if the TOC is correct? LLD assumes this: > > > > static uint64_t PPC64TocOffset = 0x8000; > > > > 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 = In::Got->getVA(); > > > > // 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; > > } > > [I warn that I'm outside familiar territory here.] > > If I understand the 1st comment right the following does not look > like a match for -fuse-dl=lld (readelf -a output): > > 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 > > Possibly contributing reasons: > > 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. > > [I guess that .rela.plt does not matter but I showed it > in case I'm wrong.] > > 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. > > > By contrast for -fuse-dl-bfd I see: > > 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 > > So no .toc or .tocbase sections. > > 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. > > So my guess is that -fuse-dl-bfd looks to be as expected, > unlike -fuse-dl=lld . > > > > 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: > > > > // 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. > > > > 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). > > > > I suspect there might be some Linux vs FreeBSD difference that prevents this from working. > > > > Roman > > === > Mark Millard > markmi at dsl-only.net > > On Thu, Jan 12, 2017 at 12:37:53AM -0800, Mark Millard wrote: > > On 2017-Jan-11, at 1:23 PM, Ed Maste wrote: > > > >> On 11 January 2017 at 21:06, Roman Divacky wrote: > >>> Looks like a progress :) Three questions... > >>> > >>> Is the readelf -a reasonable now? > >> > >> FYI, I just committed an ELF Tool Chain fix (r311941) so readelf > >> should display the relocation types properly now. > > > > Thanks. I updated to -r311950 to pick this up. > > > >>> 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. > > > > I had compiled with -g. It never gets to main. . . > > > > # /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 > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x000000001001056c in ?? () > > > > Note that the temporary breakpoint is never hit. > > > > (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 > > > > (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 > > => 0x00000000500279b0 <+128>: li r0,1 > > 0x00000000500279b4 <+132>: sc > > 0x00000000500279b8 <+136>: nop > > 0x00000000500279bc <+140>: nop > > End of assembler dump. > > > > So setting a breakpoint at 0x00000000500279ac and > > trying again: > > > > (gdb) run > > Starting program: /root/c_tests/a.out > > > > 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 ?? () > > > > and that is effectively at ._start . > > > > NOTE: There is no ._start name in the disassembly > > listed by objdump. > > > > By contrast for -fuse-ld=bfd building a.out objdump shows: > > > > 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) > > . . . > > > > > > In gdb for ld.lld used: > > > > Reading symbols from a.out...done. > > (gdb) br *0x00000000500279ac > > Breakpoint 1 at 0x500279ac > > (gdb) run > > Starting program: /root/c_tests/a.out > > > > 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) > > 0x0000000010010004 in ?? () > > (gdb) display/i $pc > > 1: x/i $pc > > => 0x10010004: mfcr r12 > > (gdb) stepi > > 0x0000000010010008 in ?? () > > 1: x/i $pc > > => 0x10010008: std r31,-8(r1) > > (gdb) > > 0x000000001001000c in ?? () > > 1: x/i $pc > > => 0x1001000c: std r0,16(r1) > > > > . . . > > > > (gdb) > > 0x00000000100100a0 in ?? () > > 1: x/i $pc > > => 0x100100a0: beq 0x100100ac > > (gdb) > > 0x00000000100100ac in ?? () > > 1: x/i $pc > > => 0x100100ac: cmpldi r8,0 > > (gdb) > > 0x00000000100100b0 in ?? () > > 1: x/i $pc > > => 0x100100b0: beq 0x100100c0 > > (gdb) > > 0x00000000100100c0 in ?? () > > 1: x/i $pc > > => 0x100100c0: addis r3,r2,0 > > (gdb) > > 0x00000000100100c4 in ?? () > > 1: x/i $pc > > => 0x100100c4: ld r3,32552(r3) > > (gdb) > > 0x00000000100100c8 in ?? () > > 1: x/i $pc > > => 0x100100c8: cmpldi r3,0 > > (gdb) > > 0x00000000100100cc in ?? () > > 1: x/i $pc > > => 0x100100cc: beq 0x100100e0 > > (gdb) > > 0x00000000100100d0 in ?? () > > 1: x/i $pc > > => 0x100100d0: mr r3,r7 > > (gdb) > > 0x00000000100100d4 in ?? () > > 1: x/i $pc > > => 0x100100d4: bl 0x10010560 > > > > Note: Below is from plt : > > > > 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) <<<<<===== 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 > > > > (By setting breakpoints in the 3 such .plt code blocks: > > this is the first .plt code block executed and it fails.) > > > > 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. > > > > Back to gdb based information: > > > > (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 > > > > (gdb) > > 0x0000000010010560 in ?? () > > 1: x/i $pc > > => 0x10010560: std r2,40(r1) > > (gdb) > > 0x0000000010010564 in ?? () > > 1: x/i $pc > > => 0x10010564: addis r11,r2,0 > > (gdb) > > 0x0000000010010568 in ?? () > > 1: x/i $pc > > => 0x10010568: ld r12,32512(r11) > > (gdb) > > 0x000000001001056c in ?? () > > 1: x/i $pc > > => 0x1001056c: ld r11,0(r12) > > (gdb) > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x000000001001056c in ?? () > > 1: x/i $pc > > => 0x1001056c: ld r11,0(r12) > > > > The source code (from lib/csu/powerpc64/crt1.c ) is: > > > > void > > _start(int argc, char **argv, char **env, > > const struct Struct_Obj_Entry *obj __unused, void (*cleanup)(void), > > struct ps_strings *ps_strings) > > { > > > > handle_argv(argc, argv, env); > > > > if (ps_strings != (struct ps_strings *)0) > > __ps_strings = ps_strings; > > > > if (&_DYNAMIC != NULL) > > atexit(cleanup); > > else > > _init_tls(); > > > > #ifdef GCRT > > atexit(_mcleanup); > > monstartup(&eprol, &etext); > > #endif > > > > handle_static_init(argc, argv, env); > > exit(main(argc, argv, env)); > > } > > > > The 3 plt code blocks are for: > > > > atexit > > _init_tls > > exit > > > > from what I can tell, possibly not in that order. > > > > Overall: The plt handling seems to be broken. > > > > > >> 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+=-DDEBUG to the > >> Makefile in my test tree and built it along with the rest of my full > >> cross build. > > > > # svnlite diff /usr/src/libexec/rtld-elf/Makefile > > Index: /usr/src/libexec/rtld-elf/Makefile > > =================================================================== > > --- /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= rtld.1 > > CSTD?= gnu99 > > +CFLAGS+=-DDEBUG > > CFLAGS+= -Wall -DFREEBSD_ELF -DIN_RTLD -ffreestanding > > CFLAGS+= -I${SRCTOP}/lib/csu/common > > .if exists(${.CURDIR}/${MACHINE_ARCH}) > > > > 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/ . > > > > > > === > > Mark Millard > > markmi at dsl-only.net > > _______________________________________________ > 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" From owner-freebsd-toolchain@freebsd.org Mon Jan 16 19:53:57 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 394EFCB35F3 for ; Mon, 16 Jan 2017 19:53:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 28C931A68 for ; Mon, 16 Jan 2017 19:53:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0GJruBe068546 for ; Mon, 16 Jan 2017 19:53:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216117] clang 4.0.0 crashes trying to build lld on i386 Date: Mon, 16 Jan 2017 19:53:57 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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 19:53:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216117 --- Comment #6 from commit-hook@freebsd.org --- A commit references this bug: Author: dim Date: Mon Jan 16 19:53:19 UTC 2017 New revision: 312308 URL: https://svnweb.freebsd.org/changeset/base/312308 Log: Pull in r292133 from upstream llvm trunk (by Hal Finkel): Fix use-after-free bug in AffectedValueCallbackVH::allUsesReplacedWith When transferring affected values in the cache from an old value, identified by the value of the current callback, to the specified new value we might need to insert a new entry into the DenseMap which constitutes the cache. Doing so might delete the current callback object. Move the copying logic into a new function, a member of the assumption cache itself, so that we don't run into UB should the callback handle itself be removed mid-copy. Differential Revision: https://reviews.llvm.org/D28749 This should fix crashes when building lld (as part of the llvmXY ports). Reported by: jbeich PR: 216117 Changes: projects/clang400-import/contrib/llvm/include/llvm/Analysis/AssumptionCac= he.h projects/clang400-import/contrib/llvm/lib/Analysis/AssumptionCache.cpp --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Jan 16 19:54:46 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 8119DCB3618 for ; Mon, 16 Jan 2017 19:54:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 70B481AAA for ; Mon, 16 Jan 2017 19:54:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0GJskWO070389 for ; Mon, 16 Jan 2017 19:54:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216117] clang 4.0.0 crashes trying to build lld on i386 Date: Mon, 16 Jan 2017 19:54:46 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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 19:54:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216117 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Closed Resolution|--- |FIXED --- Comment #7 from Dimitry Andric --- Should be fixed now, as of r312308. --=20 You are receiving this mail because: You are the assignee for the bug.= 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" From owner-freebsd-toolchain@freebsd.org Mon Jan 16 22:32:49 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 B3939CB33EA for ; Mon, 16 Jan 2017 22:32:49 +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 71A59106A for ; Mon, 16 Jan 2017 22:32:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15698 invoked from network); 16 Jan 2017 22:34:19 -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 22:34:19 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Mon, 16 Jan 2017 17:32:48 -0500 (EST) Received: (qmail 29623 invoked from network); 16 Jan 2017 22:32:47 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 16 Jan 2017 22:32:47 -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 064CEEC8AC0; Mon, 16 Jan 2017 14:32:46 -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: <2B1414C5-C56D-42F2-A1CB-4B1FE074667B@dsl-only.net> Date: Mon, 16 Jan 2017 14:32:46 -0800 Cc: FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <43DBF7C7-6632-4906-BB37-FD00621AF857@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> <2B1414C5-C56D-42F2-A1CB-4B1FE074667B@dsl-only.net> 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 22:32:49 -0000 Here is a more direct list of section addresse rangess from gdb for ld.lld output: (I've added comments on the right.) (gdb) info file Symbols from "/root/c_tests/a.out". 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 = <<<<<=3D=3D=3D=3D=3D note 0x0000000010000468 - 0x0000000010000474 is .eh_frame_hdr 0x0000000010010000 - 0x00000000100104f8 is .text 0x0000000010010500 - 0x000000001001052c is .init 0x0000000010010530 - 0x0000000010010554 is .fini 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!!!! 0x00000000100300a0 - 0x0000000010030160 is .opd 0x0000000010030160 - 0x0000000010030170 is .bss It matches the readelf and objdump output reports. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-16, at 1:39 PM, Mark Millard wrote: > On 2017-Jan-16, at 11:40 AM, Roman Divacky = wrote: >=20 >> I think the TOC (.got + .plt) has to be contiguous in memory. The = on-disk >> layout is not that important. >=20 > 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. >=20 > (Later in repsonse t your question I show what I expect is a = sufficient > confirmation.) >=20 > Note: objdump and readelf agree (VMA and LMA). Here is the objdump > equivalent: >=20 > 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 > . . . >=20 >=20 >> Can you check whats the difference of the in-memory TOC between lld = and ld.bfd? >=20 > 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. >=20 > 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. >=20 > 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.) >=20 > 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 >=20 > Examples of gdb reporting symbol information for some of those = addresses: >=20 > (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 >=20 > ld.lld (as configured?) just does not set up for the sections to have > the property: >=20 > .got, .toc, .tocbss, .plt in that order >=20 > (in memory) and ld.lld (as configured?) puts out sections that ld.bfd > does not: >=20 > .got.plt > .toc >=20 > 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. >=20 =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" _______________________________________________ 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" From owner-freebsd-toolchain@freebsd.org Mon Jan 16 23:28:41 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 561FECB2535 for ; Mon, 16 Jan 2017 23:28:41 +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 172381987 for ; Mon, 16 Jan 2017 23:28:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21295 invoked from network); 16 Jan 2017 23:28:34 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 16 Jan 2017 23:28:34 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Mon, 16 Jan 2017 18:28:34 -0500 (EST) Received: (qmail 4585 invoked from network); 16 Jan 2017 23:28:33 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 16 Jan 2017 23:28:33 -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 0CD42EC7B24; Mon, 16 Jan 2017 15:28:33 -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: <43DBF7C7-6632-4906-BB37-FD00621AF857@dsl-only.net> Date: Mon, 16 Jan 2017 15:28:32 -0800 Cc: FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <82402941-D1B2-4938-A43D-E21A390DE041@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> <2B1414C5-C56D-42F2-A1CB-4B1FE074667B@dsl-only.net> <43DBF7C7-6632-4906-BB37-FD00621AF857@dsl-only.net> 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 23:28:41 -0000 Looking up definitions of the section naming (using http://www.cs.stevens.edu/~jschauma/810/elf.html ). . . (Intel context) It looks like the RELRO segment (program header information) requires the .got section to be with the .ctors, .dtros, .jcr and such sections: .got is supposed to be inside the RELRO region. ld.lld output was using RELRO. Quoting the description of RELRO: GNU_RELRO: This segment indicates the memory region which should be made Read-Only = after relocation is done. This segment usually appears in a dynamic link = library and it contains .ctors, .dtors, .dynamic, .got sections. See = paragraph below. BUT NOTE: The ld.lld output has .jcr section in the RELRO segment and = the .dynamic just after it. Showing the objdump output for RELRO: RELRO off 0x0000000000020000 vaddr 0x0000000010020000 paddr = 0x0000000010020000 align 2**0 filesz 0x0000000000000138 memsz 0x0000000000000138 flags r-- .got.plt and .toc do not go in the RELRO segment. Quoting section descriptions. . . .rela.plt: Runtime/Dynamic relocation table. This relocation table is similar to the one in .rela.dyn section; the = difference is this one is for functions, not variables. The relocation type of entries in this table is R_386_JMP_SLOT or = R_X86_64_JUMP_SLOT and the "offset" refers to memory addresses which are = inside .got.plt section. Simply put, this table holds information to relocate entries in .got.plt = section. .got: For dynamic binaries, this Global Offset Table holds the addresses of = variables which are relocated upon loading. [Note: .got was empty because of a lack of global variables. But it was still present.] .got.plt: For dynamic binaries, this Global Offset Table holds the addresses of = functions in dynamic libraries. They are used by trampoline code in .plt = section. If .got.plt section is present, it contains at least three = entries, which have special meanings. .toc: Was not listed. (Likely powerpc64 and/or powerpc specific.) So ld.lld is keeping the .got with the other RELRO materials, as it is supposed to. And is setting up to allow lazy binding (.got.plt). It did keep the non-RELRO materials .got.plt and .toc together. But .plt is off by itself, before both the RELRO segment and the .got.plt/.toc pair. As far as I can tell the powerpc and powerpc64 FreeBSD code is not set up for any variation of such things. It may be that changes are needed to allow RELRO with the .got inside, for example. It is not obvious that disabling RELRO in ld.lld would change the order and contiguity in memory to what powerpc and powerpc64 FreeBSD expect. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-16, at 2:32 PM, Mark Millard wrote: Here is a more direct list of section addresse rangess from gdb for ld.lld output: (I've added comments on the right.) (gdb) info file Symbols from "/root/c_tests/a.out". 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 = <<<<<=3D=3D=3D=3D=3D note 0x0000000010000468 - 0x0000000010000474 is .eh_frame_hdr 0x0000000010010000 - 0x00000000100104f8 is .text 0x0000000010010500 - 0x000000001001052c is .init 0x0000000010010530 - 0x0000000010010554 is .fini 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!!!! 0x00000000100300a0 - 0x0000000010030160 is .opd 0x0000000010030160 - 0x0000000010030170 is .bss It matches the readelf and objdump output reports. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-16, at 1:39 PM, Mark Millard wrote: > On 2017-Jan-16, at 11:40 AM, Roman Divacky = wrote: >=20 >> I think the TOC (.got + .plt) has to be contiguous in memory. The = on-disk >> layout is not that important. >=20 > 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. >=20 > (Later in repsonse t your question I show what I expect is a = sufficient > confirmation.) >=20 > Note: objdump and readelf agree (VMA and LMA). Here is the objdump > equivalent: >=20 > 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 > . . . >=20 >=20 >> Can you check whats the difference of the in-memory TOC between lld = and ld.bfd? >=20 > 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. >=20 > 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. >=20 > 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.) >=20 > 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 >=20 > Examples of gdb reporting symbol information for some of those = addresses: >=20 > (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 >=20 > ld.lld (as configured?) just does not set up for the sections to have > the property: >=20 > .got, .toc, .tocbss, .plt in that order >=20 > (in memory) and ld.lld (as configured?) puts out sections that ld.bfd > does not: >=20 > .got.plt > .toc >=20 > 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. >=20 =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" _______________________________________________ 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" _______________________________________________ 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" From owner-freebsd-toolchain@freebsd.org Mon Jan 16 23:40:03 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 F020BCB29F8 for ; Mon, 16 Jan 2017 23:40:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 ACA591E23 for ; Mon, 16 Jan 2017 23:40:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26867 invoked from network); 16 Jan 2017 23:39:56 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 16 Jan 2017 23:39:56 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Mon, 16 Jan 2017 18:39:56 -0500 (EST) Received: (qmail 26219 invoked from network); 16 Jan 2017 23:39:56 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 16 Jan 2017 23:39:56 -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 5665BEC8B1E; Mon, 16 Jan 2017 15:39:55 -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: <82402941-D1B2-4938-A43D-E21A390DE041@dsl-only.net> Date: Mon, 16 Jan 2017 15:39:54 -0800 Cc: FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: 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> <2B1414C5-C56D-42F2-A1CB-4B1FE074667B@dsl-only.net> <43DBF7C7-6632-4906-BB37-FD00621AF857@dsl-only.net> <82402941-D1B2-4938-A43D-E21A390DE041@dsl-only.net> 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 23:40:04 -0000 [Correcting a poor wording/interpetatation.] On 2017-Jan-16, at 3:28 PM, Mark Millard wrote: > Looking up definitions of the section naming > (using http://www.cs.stevens.edu/~jschauma/810/elf.html ). . . > (Intel context) >=20 >=20 > It looks like the RELRO segment (program header information) requires > the .got section to be with the .ctors, .dtros, .jcr and such = sections: > .got is supposed to be inside the RELRO region. ld.lld output was = using > RELRO. Quoting the description of RELRO: >=20 > GNU_RELRO: >=20 > This segment indicates the memory region which should be made = Read-Only after relocation is done. This segment usually appears in a = dynamic link library and it contains .ctors, .dtors, .dynamic, .got = sections. See paragraph below. >=20 > BUT NOTE: The ld.lld output has .jcr section in the RELRO segment and = the .dynamic just after it. That "BUT NOTE" is wrong because both .dynamic and .got were empty and = so are not really outside the RELRO region: just at the boundary. If they had some positive size = then the end of RELRO would be after those sections start and would include their content. > Showing the objdump output for RELRO: >=20 > RELRO off 0x0000000000020000 vaddr 0x0000000010020000 paddr = 0x0000000010020000 align 2**0 > filesz 0x0000000000000138 memsz 0x0000000000000138 flags r-- >=20 > .got.plt and .toc do not go in the RELRO segment. >=20 >=20 > Quoting section descriptions. . . >=20 >=20 > .rela.plt: >=20 > Runtime/Dynamic relocation table. > This relocation table is similar to the one in .rela.dyn section; the = difference is this one is for functions, not variables. >=20 > The relocation type of entries in this table is R_386_JMP_SLOT or = R_X86_64_JUMP_SLOT and the "offset" refers to memory addresses which are = inside .got.plt section. >=20 > Simply put, this table holds information to relocate entries in = .got.plt section. >=20 >=20 > .got: > For dynamic binaries, this Global Offset Table holds the addresses of = variables which are relocated upon loading. >=20 > [Note: .got was empty because of a lack of global variables. But it > was still present.] >=20 >=20 > .got.plt: >=20 > For dynamic binaries, this Global Offset Table holds the addresses of = functions in dynamic libraries. They are used by trampoline code in .plt = section. If .got.plt section is present, it contains at least three = entries, which have special meanings. >=20 >=20 > .toc: >=20 > Was not listed. (Likely powerpc64 and/or powerpc specific.) >=20 >=20 >=20 > So ld.lld is keeping the .got with the other RELRO materials, > as it is supposed to. >=20 > And is setting up to allow lazy binding (.got.plt). >=20 > It did keep the non-RELRO materials .got.plt and .toc together. > But .plt is off by itself, before both the RELRO segment and the > .got.plt/.toc pair. >=20 >=20 >=20 > As far as I can tell the powerpc and powerpc64 FreeBSD code is > not set up for any variation of such things. >=20 > It may be that changes are needed to allow RELRO with the .got > inside, for example. >=20 > It is not obvious that disabling RELRO in ld.lld would change > the order and contiguity in memory to what powerpc and powerpc64 > FreeBSD expect. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-16, at 2:32 PM, Mark Millard wrote: Here is a more direct list of section addresse rangess from gdb for ld.lld output: (I've added comments on the right.) (gdb) info file Symbols from "/root/c_tests/a.out". 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 = <<<<<=3D=3D=3D=3D=3D note 0x0000000010000468 - 0x0000000010000474 is .eh_frame_hdr 0x0000000010010000 - 0x00000000100104f8 is .text 0x0000000010010500 - 0x000000001001052c is .init 0x0000000010010530 - 0x0000000010010554 is .fini 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!!!! 0x00000000100300a0 - 0x0000000010030160 is .opd 0x0000000010030160 - 0x0000000010030170 is .bss It matches the readelf and objdump output reports. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-16, at 1:39 PM, Mark Millard wrote: > On 2017-Jan-16, at 11:40 AM, Roman Divacky = wrote: >=20 >> I think the TOC (.got + .plt) has to be contiguous in memory. The = on-disk >> layout is not that important. >=20 > 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. >=20 > (Later in repsonse t your question I show what I expect is a = sufficient > confirmation.) >=20 > Note: objdump and readelf agree (VMA and LMA). Here is the objdump > equivalent: >=20 > 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 > . . . >=20 >=20 >> Can you check whats the difference of the in-memory TOC between lld = and ld.bfd? >=20 > 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. >=20 > 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. >=20 > 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.) >=20 > 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 >=20 > Examples of gdb reporting symbol information for some of those = addresses: >=20 > (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 >=20 > ld.lld (as configured?) just does not set up for the sections to have > the property: >=20 > .got, .toc, .tocbss, .plt in that order >=20 > (in memory) and ld.lld (as configured?) puts out sections that ld.bfd > does not: >=20 > .got.plt > .toc >=20 > 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. >=20 =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" _______________________________________________ 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" _______________________________________________ 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" _______________________________________________ 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" From owner-freebsd-toolchain@freebsd.org Tue Jan 17 01:18:37 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 E284ACB1E08 for ; Tue, 17 Jan 2017 01:18:37 +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 A2A9D10E8 for ; Tue, 17 Jan 2017 01:18:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15547 invoked from network); 17 Jan 2017 01:18:35 -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 01:18:35 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Mon, 16 Jan 2017 20:18:35 -0500 (EST) Received: (qmail 27203 invoked from network); 17 Jan 2017 01:18:35 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 17 Jan 2017 01:18:35 -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 D95F3EC7B24; Mon, 16 Jan 2017 17:18:34 -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: Date: Mon, 16 Jan 2017 17:18:34 -0800 Cc: FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <27422F1B-6906-4D37-860A-D1BC8DC83BBF@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> <2B1414C5-C56D-42F2-A1CB-4B1FE074667B@dsl-only.net> <43DBF7C7-6632-4906-BB37-FD00621AF857@dsl-only.net> <82402941-D1B2-4938-A43D-E21A390DE041@dsl-only.net> 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: Tue, 17 Jan 2017 01:18:38 -0000 I found some wording relating older-style .got to newer style = .got/.got.plt pair of sections (that need not be near each other). . . https://sourceware.org/ml/binutils/2004-03/msg00350.html says that the .got has been split in two: in essence the RELRO part and the non-RELRO part. Quoting: > .got.plt section contains the 3 reserved entries plus the GOT entries > corresponding to the .plt stubs. The point of separating this from > .got (where this lived at the beginning of .got, i.e. > .got : ( *(.got.plt) *(.got) ) in the linker script) is to put the = reminder > of .got to an area which can be write protected after relocation is > finished because it is constant after relocation is finished. This is = not > true for .got.plt, which is written to during lazy binding. That fits with what I've read about the end result that involves = .got.plt . =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-16, at 3:39 PM, Mark Millard wrote: > [Correcting a poor wording/interpetatation.] >=20 > On 2017-Jan-16, at 3:28 PM, Mark Millard wrote: >=20 >> Looking up definitions of the section naming >> (using http://www.cs.stevens.edu/~jschauma/810/elf.html ). . . >> (Intel context) >>=20 >>=20 >> It looks like the RELRO segment (program header information) requires >> the .got section to be with the .ctors, .dtros, .jcr and such = sections: >> .got is supposed to be inside the RELRO region. ld.lld output was = using >> RELRO. Quoting the description of RELRO: >>=20 >> GNU_RELRO: >>=20 >> This segment indicates the memory region which should be made = Read-Only after relocation is done. This segment usually appears in a = dynamic link library and it contains .ctors, .dtors, .dynamic, .got = sections. See paragraph below. >>=20 >> BUT NOTE: The ld.lld output has .jcr section in the RELRO segment and = the .dynamic just after it. >=20 > That "BUT NOTE" is wrong because both .dynamic and .got were empty and = so are not really outside > the RELRO region: just at the boundary. If they had some positive size = then the end of RELRO > would be after those sections start and would include their content. >=20 >> Showing the objdump output for RELRO: >>=20 >> RELRO off 0x0000000000020000 vaddr 0x0000000010020000 paddr = 0x0000000010020000 align 2**0 >> filesz 0x0000000000000138 memsz 0x0000000000000138 flags r-- >>=20 >> .got.plt and .toc do not go in the RELRO segment. >>=20 >>=20 >> Quoting section descriptions. . . >>=20 >>=20 >> .rela.plt: >>=20 >> Runtime/Dynamic relocation table. >> This relocation table is similar to the one in .rela.dyn section; the = difference is this one is for functions, not variables. >>=20 >> The relocation type of entries in this table is R_386_JMP_SLOT or = R_X86_64_JUMP_SLOT and the "offset" refers to memory addresses which are = inside .got.plt section. >>=20 >> Simply put, this table holds information to relocate entries in = .got.plt section. >>=20 >>=20 >> .got: >> For dynamic binaries, this Global Offset Table holds the addresses of = variables which are relocated upon loading. >>=20 >> [Note: .got was empty because of a lack of global variables. But it >> was still present.] >>=20 >>=20 >> .got.plt: >>=20 >> For dynamic binaries, this Global Offset Table holds the addresses of = functions in dynamic libraries. They are used by trampoline code in .plt = section. If .got.plt section is present, it contains at least three = entries, which have special meanings. >>=20 >>=20 >> .toc: >>=20 >> Was not listed. (Likely powerpc64 and/or powerpc specific.) >>=20 >>=20 >>=20 >> So ld.lld is keeping the .got with the other RELRO materials, >> as it is supposed to. >>=20 >> And is setting up to allow lazy binding (.got.plt). >>=20 >> It did keep the non-RELRO materials .got.plt and .toc together. >> But .plt is off by itself, before both the RELRO segment and the >> .got.plt/.toc pair. >>=20 >>=20 >>=20 >> As far as I can tell the powerpc and powerpc64 FreeBSD code is >> not set up for any variation of such things. >>=20 >> It may be that changes are needed to allow RELRO with the .got >> inside, for example. >>=20 >> It is not obvious that disabling RELRO in ld.lld would change >> the order and contiguity in memory to what powerpc and powerpc64 >> FreeBSD expect. >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net On 2017-Jan-16, at 2:32 PM, Mark Millard wrote: Here is a more direct list of section addresse rangess from gdb for ld.lld output: (I've added comments on the right.) (gdb) info file Symbols from "/root/c_tests/a.out". 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 = <<<<<=3D=3D=3D=3D=3D note 0x0000000010000468 - 0x0000000010000474 is .eh_frame_hdr 0x0000000010010000 - 0x00000000100104f8 is .text 0x0000000010010500 - 0x000000001001052c is .init 0x0000000010010530 - 0x0000000010010554 is .fini 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!!!! 0x00000000100300a0 - 0x0000000010030160 is .opd 0x0000000010030160 - 0x0000000010030170 is .bss It matches the readelf and objdump output reports. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-16, at 1:39 PM, Mark Millard wrote: > On 2017-Jan-16, at 11:40 AM, Roman Divacky = wrote: >=20 >> I think the TOC (.got + .plt) has to be contiguous in memory. The = on-disk >> layout is not that important. >=20 > 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. >=20 > (Later in repsonse t your question I show what I expect is a = sufficient > confirmation.) >=20 > Note: objdump and readelf agree (VMA and LMA). Here is the objdump > equivalent: >=20 > 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 > . . . >=20 >=20 >> Can you check whats the difference of the in-memory TOC between lld = and ld.bfd? >=20 > 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. >=20 > 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. >=20 > 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.) >=20 > 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 >=20 > Examples of gdb reporting symbol information for some of those = addresses: >=20 > (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 >=20 > ld.lld (as configured?) just does not set up for the sections to have > the property: >=20 > .got, .toc, .tocbss, .plt in that order >=20 > (in memory) and ld.lld (as configured?) puts out sections that ld.bfd > does not: >=20 > .got.plt > .toc >=20 > 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. >=20 =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" _______________________________________________ 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" _______________________________________________ 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" _______________________________________________ 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" _______________________________________________ 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" From owner-freebsd-toolchain@freebsd.org Tue Jan 17 02:47:15 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 D7E89CB24E9; Tue, 17 Jan 2017 02:47:15 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F1221119; Tue, 17 Jan 2017 02:47:15 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-io0-x244.google.com with SMTP id c80so14494492iod.1; Mon, 16 Jan 2017 18:47:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=cc:message-id:from:to:in-reply-to:content-transfer-encoding :mime-version:subject:date:references; bh=ZrGTEk/NIEaj+Nj09uEDG0cVV60iSM0wIwK5oj+Gh4c=; b=C5g4OHl02xHFxeIBc+RqZkNonCGPoxAZn6HRTx4P25H758TOM/lV4vr9MVv00HGSap a+BqeWT8pS9MJIDFH6nkpnLwuVKzB4bsbQjR7vJJIEf/Yt/NH0XX/tGuvu38whQg3CWw Ufq02xl9kmboWJ5DiX/pn3ZkGvvuZ1b/IdzdXJrjE1HHQIEWMxXMMmEXV5gsOGMFkzTw HbOt4ANEZ4wI+VxGfia7KjB3cNm8VZo+g2p1WoTzsqD2fFeKbOuHRfeVUArsOekLKUYs IWlh2fRa+KxGFoTvxP8gXJorSlGJm90nzERe7iS6JbZVx5etN37c3UHDjg9Q+EHvcJw5 s/+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:cc:message-id:from:to:in-reply-to :content-transfer-encoding:mime-version:subject:date:references; bh=ZrGTEk/NIEaj+Nj09uEDG0cVV60iSM0wIwK5oj+Gh4c=; b=XzIWgfzB8tUtRGRFwqkWaA/IojV//AFHQyH84uZUcAk1aPRd8myw3jLmp8sU+fuTLh U9INjaI9Zddrh9mG42KUz1hcRyNYV7O9nLaxeFqf/K0pAnxjyy9P65Qj+m4y+1zvcFDm dEkDY5fQnkrt3PRZ4ZZPbsWdaAoB5A3YjJSe9ovg3DhYQyZ/PQZt+makdnNaQd5ifcsh 1AXtak4x7rtua6Ln7ZFCj3Po7tXVMQK0fka6X0lxDMT3KKbcM3vPN0fPbjC6VmC4avVH cZ6Woul1zg1ZYmNNdi9eJCdrx23bOA4KC0a/uFhEXK4bGVHFtFMNqSBR4f5UydkAsqqu t7ug== X-Gm-Message-State: AIkVDXIBxDU7OIVKf68Wv9/jv5NiFKF2DE5g4xLubapcZT4BtsvriDhxa6Ls9n5lvETXqQ== X-Received: by 10.107.132.81 with SMTP id g78mr34507293iod.227.1484621234933; Mon, 16 Jan 2017 18:47:14 -0800 (PST) Received: from blackstar.knownspace (50-80-150-234.client.mchsi.com. [50.80.150.234]) by smtp.gmail.com with ESMTPSA id 191sm12310850ioe.37.2017.01.16.18.47.13 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 16 Jan 2017 18:47:14 -0800 (PST) Cc: Mark Millard , FreeBSD Toolchain , FreeBSD PowerPC ML Message-Id: From: Justin Hibbits To: Roman Divacky In-Reply-To: <20161205161904.GA7889@vlakno.cz> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . Date: Mon, 16 Jan 2017 20:45:58 -0600 References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net> <20161205161904.GA7889@vlakno.cz> X-Mailer: Apple Mail (2.936) 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 02:47:15 -0000 The patch is incorrect, the 'xo' values are off by one bit (inline change): On Dec 5, 2016, at 10:19 AM, Roman Divacky wrote: > Can you try this patch? > > Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td > =================================================================== > --- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675) > +++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) > @@ -2373,6 +2373,12 @@ > def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), > "mftb $RT, $SPR", IIC_SprMFTB>; > > +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), 334 should be 167 > + "mfpmr $RT, $PMRN", IIC_IntGeneral>; > + > +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), > + "mtpmr $PMRN, $RS", IIC_IntGeneral>; 462 should be 231. > + > // A pseudo-instruction used to implement the read of the 64-bit > cycle counter > // on a 32-bit target. > let hasSideEffects = 1, usesCustomInserter = 1 in > I'll have a patch ready for LLVM review within a week or so, including some level of scheduling. - Justin From owner-freebsd-toolchain@freebsd.org Tue Jan 17 16:58:49 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 B52E0CB4328 for ; Tue, 17 Jan 2017 16:58:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 A45C61ADF for ; Tue, 17 Jan 2017 16:58:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0HGwnMQ091313 for ; Tue, 17 Jan 2017 16:58:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216166] graphics/gegl3: clang 4.0 crashes during build Date: Tue, 17 Jan 2017 16:58:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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 16:58:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216166 Jan Beich (mail not working) changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|gnome@FreeBSD.org |freebsd-toolchain@FreeBSD.o | |rg Flags|maintainer-feedback?(gnome@ | |FreeBSD.org) | --- Comment #3 from Jan Beich (mail not working) --- Can you reproduce on /projects/clang400-import@312309 or devel/llvm-devel a= fter editing .sh file? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Jan 17 18:30:04 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 170EFCB4F02 for ; Tue, 17 Jan 2017 18:30:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 E38A5194F for ; Tue, 17 Jan 2017 18:30:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0HIU3p0018295 for ; Tue, 17 Jan 2017 18:30:03 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216166] graphics/gegl3: clang 4.0 crashes during build Date: Tue, 17 Jan 2017 18:30:04 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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 18:30:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216166 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dim@FreeBSD.org Status|New |In Progress --- Comment #4 from Dimitry Andric --- (In reply to Jan Beich (mail not working) from comment #3) > Can you reproduce on /projects/clang400-import@312309 or devel/llvm-devel > after editing .sh file? Yes, I can reproduce with clang 4.0.0 (branches/release_40 292009) (as in t= he clang400-import branch). Investigating... --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Jan 17 19:23:32 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 0386ACB42E2 for ; Tue, 17 Jan 2017 19:23:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 E70771D08 for ; Tue, 17 Jan 2017 19:23:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0HJNV3h051455 for ; Tue, 17 Jan 2017 19:23:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216166] graphics/gegl3: clang 4.0 crashes during build Date: Tue, 17 Jan 2017 19:23:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: dim@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to bug_file_loc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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 19:23:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216166 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-toolchain@FreeBSD.o |dim@FreeBSD.org |rg | URL| |https://llvm.org/bugs/show_ | |bug.cgi?id=3D31672 --- Comment #5 from Dimitry Andric --- Minimized a test case, and submitted it upstream as https://llvm.org/bugs/show_bug.cgi?id=3D31672 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Jan 17 19:49:28 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 27A02CB4B91; Tue, 17 Jan 2017 19:49:28 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id E3CAF1E6D; Tue, 17 Jan 2017 19:49:27 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id 9C74F12CB9F; Tue, 17 Jan 2017 20:46:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1484682411; bh=3Ml3gY/QKFO0dHMw4929LDJXxsyMwi2dL9NiY46f0x8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=PjzjUGWmJly+QO0Oc+NIavGY+ZlKO2+Cut1BqYK5QRgX+66gvFe7uSW64laLb8omW A18mvJ2iSBsjk2Z58ucMZLHJZZl6mS/kMbjop1JaBYc5u2enIoMKM0y5Mb17BTok7j Im7J80qcdMc9wooBm0GYOfI/joDZttfA1iw8OeK8= Date: Tue, 17 Jan 2017 20:46:51 +0100 From: Roman Divacky To: Justin Hibbits Cc: Mark Millard , FreeBSD Toolchain , FreeBSD PowerPC ML Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . Message-ID: <20170117194651.GA88907@vlakno.cz> References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net> <20161205161904.GA7889@vlakno.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) 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 19:49:28 -0000 Are you sure? My coy of PowerISA lists the numbers that I used? What makes you think it should be shifted by one bit? On Mon, Jan 16, 2017 at 08:45:58PM -0600, Justin Hibbits wrote: > The patch is incorrect, the 'xo' values are off by one bit (inline > change): > > > On Dec 5, 2016, at 10:19 AM, Roman Divacky wrote: > > > Can you try this patch? > > > > Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td > > =================================================================== > > --- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675) > > +++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) > > @@ -2373,6 +2373,12 @@ > > def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), > > "mftb $RT, $SPR", IIC_SprMFTB>; > > > > +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), > > 334 should be 167 > > > + "mfpmr $RT, $PMRN", IIC_IntGeneral>; > > + > > +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), > > + "mtpmr $PMRN, $RS", IIC_IntGeneral>; > > 462 should be 231. > > > + > > // A pseudo-instruction used to implement the read of the 64-bit > > cycle counter > > // on a 32-bit target. > > let hasSideEffects = 1, usesCustomInserter = 1 in > > > > I'll have a patch ready for LLVM review within a week or so, including > some level of scheduling. > > - Justin From owner-freebsd-toolchain@freebsd.org Tue Jan 17 19:56:54 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 BC994CB4E01 for ; Tue, 17 Jan 2017 19:56:54 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id 3EC33125E; Tue, 17 Jan 2017 19:56:54 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id C1C2112CCC9; Tue, 17 Jan 2017 20:54:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1484682864; bh=zs0dpU+rAaAYbpOQLsneyJ9L4C2yeBSf74vz56v9UEU=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=N1jgkWOk+42FWuEAfpBTfbdomo0eD2P/tks0xNudhM1PYYvIvEknZmDIMaTTIGl1z qjGw7hUBNIDMBwI0zGNiQ0QEbICCma9ajUR6aTyFqJ4KMLb0OR9rr4Or3T406Clb/m eB3CPix9gIBE0VUZLPBUSmgHZWIwWMtGsfdzMotk= Date: Tue, 17 Jan 2017 20:54:24 +0100 From: Roman Divacky To: Mark Millard Cc: Ed Maste , FreeBSD Toolchain 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: <20170117195424.GA89237@vlakno.cz> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27422F1B-6906-4D37-860A-D1BC8DC83BBF@dsl-only.net> User-Agent: Mutt/1.7.2 (2016-11-26) 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 19:56:54 -0000 Mark, I wonder if it doesnt work because of my first patch (the one to turn GOT reloc into PLT one). LLD understands that we use GOT as TOC (which was true before my patch), I wonder if something like this: ndex: tools/lld/ELF/Target.cpp =================================================================== --- tools/lld/ELF/Target.cpp (revision 292071) +++ tools/lld/ELF/Target.cpp (working copy) @@ -1070,7 +1070,8 @@ } PPC64TargetInfo::PPC64TargetInfo() { - PltRel = GotRel = R_PPC64_GLOB_DAT; + GotRel = R_PPC64_GLOB_DAT; + PltRel = R_PPC64_JMP_SLOT; RelativeRel = R_PPC64_RELATIVE; GotEntrySize = 8; GotPltEntrySize = 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 = In::Got->getVA(); + uint64_t TocVA = In::Plt->getVA(); // 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 would make any difference? It's not correct but might shed some light on what needs to be done if I am right. Could you explore this please? Thanks, Roman On Mon, Jan 16, 2017 at 05:18:34PM -0800, Mark Millard wrote: > I found some wording relating older-style .got to newer style .got/.got.plt > pair of sections (that need not be near each other). . . > > https://sourceware.org/ml/binutils/2004-03/msg00350.html > > says that the .got has been split in two: in essence the RELRO part > and the non-RELRO part. Quoting: > > > .got.plt section contains the 3 reserved entries plus the GOT entries > > corresponding to the .plt stubs. The point of separating this from > > .got (where this lived at the beginning of .got, i.e. > > .got : ( *(.got.plt) *(.got) ) in the linker script) is to put the reminder > > of .got to an area which can be write protected after relocation is > > finished because it is constant after relocation is finished. This is not > > true for .got.plt, which is written to during lazy binding. > > That fits with what I've read about the end result that involves .got.plt . > > === > Mark Millard > markmi at dsl-only.net > > On 2017-Jan-16, at 3:39 PM, Mark Millard wrote: > > > [Correcting a poor wording/interpetatation.] > > > > On 2017-Jan-16, at 3:28 PM, Mark Millard wrote: > > > >> Looking up definitions of the section naming > >> (using http://www.cs.stevens.edu/~jschauma/810/elf.html ). . . > >> (Intel context) > >> > >> > >> It looks like the RELRO segment (program header information) requires > >> the .got section to be with the .ctors, .dtros, .jcr and such sections: > >> .got is supposed to be inside the RELRO region. ld.lld output was using > >> RELRO. Quoting the description of RELRO: > >> > >> GNU_RELRO: > >> > >> This segment indicates the memory region which should be made Read-Only after relocation is done. This segment usually appears in a dynamic link library and it contains .ctors, .dtors, .dynamic, .got sections. See paragraph below. > >> > >> BUT NOTE: The ld.lld output has .jcr section in the RELRO segment and the .dynamic just after it. > > > > That "BUT NOTE" is wrong because both .dynamic and .got were empty and so are not really outside > > the RELRO region: just at the boundary. If they had some positive size then the end of RELRO > > would be after those sections start and would include their content. > > > >> Showing the objdump output for RELRO: > >> > >> RELRO off 0x0000000000020000 vaddr 0x0000000010020000 paddr 0x0000000010020000 align 2**0 > >> filesz 0x0000000000000138 memsz 0x0000000000000138 flags r-- > >> > >> .got.plt and .toc do not go in the RELRO segment. > >> > >> > >> Quoting section descriptions. . . > >> > >> > >> .rela.plt: > >> > >> Runtime/Dynamic relocation table. > >> This relocation table is similar to the one in .rela.dyn section; the difference is this one is for functions, not variables. > >> > >> The relocation type of entries in this table is R_386_JMP_SLOT or R_X86_64_JUMP_SLOT and the "offset" refers to memory addresses which are inside .got.plt section. > >> > >> Simply put, this table holds information to relocate entries in .got.plt section. > >> > >> > >> .got: > >> For dynamic binaries, this Global Offset Table holds the addresses of variables which are relocated upon loading. > >> > >> [Note: .got was empty because of a lack of global variables. But it > >> was still present.] > >> > >> > >> .got.plt: > >> > >> For dynamic binaries, this Global Offset Table holds the addresses of functions in dynamic libraries. They are used by trampoline code in .plt section. If .got.plt section is present, it contains at least three entries, which have special meanings. > >> > >> > >> .toc: > >> > >> Was not listed. (Likely powerpc64 and/or powerpc specific.) > >> > >> > >> > >> So ld.lld is keeping the .got with the other RELRO materials, > >> as it is supposed to. > >> > >> And is setting up to allow lazy binding (.got.plt). > >> > >> It did keep the non-RELRO materials .got.plt and .toc together. > >> But .plt is off by itself, before both the RELRO segment and the > >> .got.plt/.toc pair. > >> > >> > >> > >> As far as I can tell the powerpc and powerpc64 FreeBSD code is > >> not set up for any variation of such things. > >> > >> It may be that changes are needed to allow RELRO with the .got > >> inside, for example. > >> > >> It is not obvious that disabling RELRO in ld.lld would change > >> the order and contiguity in memory to what powerpc and powerpc64 > >> FreeBSD expect. > > > > > > === > > Mark Millard > > markmi at dsl-only.net > > On 2017-Jan-16, at 2:32 PM, Mark Millard wrote: > > Here is a more direct list of section addresse rangess from gdb > for ld.lld output: > (I've added comments on the right.) > > (gdb) info file > Symbols from "/root/c_tests/a.out". > 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 <<<<<===== note > 0x0000000010000468 - 0x0000000010000474 is .eh_frame_hdr > 0x0000000010010000 - 0x00000000100104f8 is .text > 0x0000000010010500 - 0x000000001001052c is .init > 0x0000000010010530 - 0x0000000010010554 is .fini > 0x0000000010010560 - 0x00000000100105c0 is .plt <<<<<===== NOTE!!!! > 0x0000000010020000 - 0x0000000010020010 is .ctors > 0x0000000010020010 - 0x0000000010020020 is .dtors > 0x0000000010020020 - 0x0000000010020028 is .jcr > 0x0000000010020028 - 0x0000000010020138 is .dynamic > 0x0000000010020138 - 0x0000000010020138 is .got <<<<<===== NOTE!!!! > 0x0000000010030000 - 0x0000000010030019 is .data > 0x0000000010030020 - 0x0000000010030050 is .got.plt <<<<<===== NOTE!!!! > 0x0000000010030050 - 0x00000000100300a0 is .toc <<<<<===== NOTE!!!! > 0x00000000100300a0 - 0x0000000010030160 is .opd > 0x0000000010030160 - 0x0000000010030170 is .bss > > It matches the readelf and objdump output reports. > > === > Mark Millard > markmi at dsl-only.net > > On 2017-Jan-16, at 1:39 PM, Mark Millard wrote: > > > 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. > > > === > Mark Millard > markmi at dsl-only.net > > On Fri, Jan 13, 2017 at 02:07:00PM -0800, Mark Millard wrote: > > Just an FYI: > > > > elfdump -a (from -r311950) does not dump .plt or .got.plt or .toc : > > > > # 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): > > > > (The "global offset table" was empty but its title was listed.) > > > > === > > Mark Millard > > markmi at dsl-only.net > > > > On 2017-Jan-12, at 5:58 PM, Mark Millard wrote: > > > > On 2017-Jan-12, at 11:22 AM, Roman Divacky wrote: > > > >> Can you check if the TOC is correct? LLD assumes this: > >> > >> static uint64_t PPC64TocOffset = 0x8000; > >> > >> 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 = In::Got->getVA(); > >> > >> // 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; > >> } > > > > [I warn that I'm outside familiar territory here.] > > > > If I understand the 1st comment right the following does not look > > like a match for -fuse-dl=lld (readelf -a output): > > > > 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 > > > > Possibly contributing reasons: > > > > 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. > > > > [I guess that .rela.plt does not matter but I showed it > > in case I'm wrong.] > > > > 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. > > > > > > By contrast for -fuse-dl-bfd I see: > > > > 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 > > > > So no .toc or .tocbase sections. > > > > 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. > > > > So my guess is that -fuse-dl-bfd looks to be as expected, > > unlike -fuse-dl=lld . > > > > > >> 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: > >> > >> // 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. > >> > >> 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). > >> > >> I suspect there might be some Linux vs FreeBSD difference that prevents this from working. > >> > >> Roman > > > > === > > Mark Millard > > markmi at dsl-only.net > > > > On Thu, Jan 12, 2017 at 12:37:53AM -0800, Mark Millard wrote: > >> On 2017-Jan-11, at 1:23 PM, Ed Maste wrote: > >> > >>> On 11 January 2017 at 21:06, Roman Divacky wrote: > >>>> Looks like a progress :) Three questions... > >>>> > >>>> Is the readelf -a reasonable now? > >>> > >>> FYI, I just committed an ELF Tool Chain fix (r311941) so readelf > >>> should display the relocation types properly now. > >> > >> Thanks. I updated to -r311950 to pick this up. > >> > >>>> 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. > >> > >> I had compiled with -g. It never gets to main. . . > >> > >> # /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 > >> > >> Program received signal SIGSEGV, Segmentation fault. > >> 0x000000001001056c in ?? () > >> > >> Note that the temporary breakpoint is never hit. > >> > >> (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 > >> > >> (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 > >> => 0x00000000500279b0 <+128>: li r0,1 > >> 0x00000000500279b4 <+132>: sc > >> 0x00000000500279b8 <+136>: nop > >> 0x00000000500279bc <+140>: nop > >> End of assembler dump. > >> > >> So setting a breakpoint at 0x00000000500279ac and > >> trying again: > >> > >> (gdb) run > >> Starting program: /root/c_tests/a.out > >> > >> 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 ?? () > >> > >> and that is effectively at ._start . > >> > >> NOTE: There is no ._start name in the disassembly > >> listed by objdump. > >> > >> By contrast for -fuse-ld=bfd building a.out objdump shows: > >> > >> 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) > >> . . . > >> > >> > >> In gdb for ld.lld used: > >> > >> Reading symbols from a.out...done. > >> (gdb) br *0x00000000500279ac > >> Breakpoint 1 at 0x500279ac > >> (gdb) run > >> Starting program: /root/c_tests/a.out > >> > >> 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) > >> 0x0000000010010004 in ?? () > >> (gdb) display/i $pc > >> 1: x/i $pc > >> => 0x10010004: mfcr r12 > >> (gdb) stepi > >> 0x0000000010010008 in ?? () > >> 1: x/i $pc > >> => 0x10010008: std r31,-8(r1) > >> (gdb) > >> 0x000000001001000c in ?? () > >> 1: x/i $pc > >> => 0x1001000c: std r0,16(r1) > >> > >> . . . > >> > >> (gdb) > >> 0x00000000100100a0 in ?? () > >> 1: x/i $pc > >> => 0x100100a0: beq 0x100100ac > >> (gdb) > >> 0x00000000100100ac in ?? () > >> 1: x/i $pc > >> => 0x100100ac: cmpldi r8,0 > >> (gdb) > >> 0x00000000100100b0 in ?? () > >> 1: x/i $pc > >> => 0x100100b0: beq 0x100100c0 > >> (gdb) > >> 0x00000000100100c0 in ?? () > >> 1: x/i $pc > >> => 0x100100c0: addis r3,r2,0 > >> (gdb) > >> 0x00000000100100c4 in ?? () > >> 1: x/i $pc > >> => 0x100100c4: ld r3,32552(r3) > >> (gdb) > >> 0x00000000100100c8 in ?? () > >> 1: x/i $pc > >> => 0x100100c8: cmpldi r3,0 > >> (gdb) > >> 0x00000000100100cc in ?? () > >> 1: x/i $pc > >> => 0x100100cc: beq 0x100100e0 > >> (gdb) > >> 0x00000000100100d0 in ?? () > >> 1: x/i $pc > >> => 0x100100d0: mr r3,r7 > >> (gdb) > >> 0x00000000100100d4 in ?? () > >> 1: x/i $pc > >> => 0x100100d4: bl 0x10010560 > >> > >> Note: Below is from plt : > >> > >> 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) <<<<<===== 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 > >> > >> (By setting breakpoints in the 3 such .plt code blocks: > >> this is the first .plt code block executed and it fails.) > >> > >> 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. > >> > >> Back to gdb based information: > >> > >> (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 > >> > >> (gdb) > >> 0x0000000010010560 in ?? () > >> 1: x/i $pc > >> => 0x10010560: std r2,40(r1) > >> (gdb) > >> 0x0000000010010564 in ?? () > >> 1: x/i $pc > >> => 0x10010564: addis r11,r2,0 > >> (gdb) > >> 0x0000000010010568 in ?? () > >> 1: x/i $pc > >> => 0x10010568: ld r12,32512(r11) > >> (gdb) > >> 0x000000001001056c in ?? () > >> 1: x/i $pc > >> => 0x1001056c: ld r11,0(r12) > >> (gdb) > >> > >> Program received signal SIGSEGV, Segmentation fault. > >> 0x000000001001056c in ?? () > >> 1: x/i $pc > >> => 0x1001056c: ld r11,0(r12) > >> > >> The source code (from lib/csu/powerpc64/crt1.c ) is: > >> > >> void > >> _start(int argc, char **argv, char **env, > >> const struct Struct_Obj_Entry *obj __unused, void (*cleanup)(void), > >> struct ps_strings *ps_strings) > >> { > >> > >> handle_argv(argc, argv, env); > >> > >> if (ps_strings != (struct ps_strings *)0) > >> __ps_strings = ps_strings; > >> > >> if (&_DYNAMIC != NULL) > >> atexit(cleanup); > >> else > >> _init_tls(); > >> > >> #ifdef GCRT > >> atexit(_mcleanup); > >> monstartup(&eprol, &etext); > >> #endif > >> > >> handle_static_init(argc, argv, env); > >> exit(main(argc, argv, env)); > >> } > >> > >> The 3 plt code blocks are for: > >> > >> atexit > >> _init_tls > >> exit > >> > >> from what I can tell, possibly not in that order. > >> > >> Overall: The plt handling seems to be broken. > >> > >> > >>> 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+=-DDEBUG to the > >>> Makefile in my test tree and built it along with the rest of my full > >>> cross build. > >> > >> # svnlite diff /usr/src/libexec/rtld-elf/Makefile > >> Index: /usr/src/libexec/rtld-elf/Makefile > >> =================================================================== > >> --- /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= rtld.1 > >> CSTD?= gnu99 > >> +CFLAGS+=-DDEBUG > >> CFLAGS+= -Wall -DFREEBSD_ELF -DIN_RTLD -ffreestanding > >> CFLAGS+= -I${SRCTOP}/lib/csu/common > >> .if exists(${.CURDIR}/${MACHINE_ARCH}) > >> > >> 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/ . > >> > >> > >> === > >> Mark Millard > >> markmi at dsl-only.net > > > > _______________________________________________ > > 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" > > _______________________________________________ > 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" > > _______________________________________________ > 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" > > _______________________________________________ > 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" > > _______________________________________________ > 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" From owner-freebsd-toolchain@freebsd.org Tue Jan 17 20:33:05 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 4C327CB4175; Tue, 17 Jan 2017 20:33:05 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05F331CAB; Tue, 17 Jan 2017 20:33:05 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-qt0-x233.google.com with SMTP id l7so178981807qtd.1; Tue, 17 Jan 2017 12:33:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZUiLChI8TlZJAnT7zw1vn7TLWt0FJRL6MChrvjmtE54=; b=kG7ewu1jYA2XQrWr3tbtxcuxD4f4kiQuLiQBx5jL1n71QYMussuTavaqJqLkj57/P8 53YUStFHeJTYH4EV91gy9di/jVkzO1nVa/H55j+/u1U8x4bA+wIRePivu4TtwEJlV9PY Pfxs6N06JFXIHcGr3F2UwnSIJL4Jp4+z3uCE0zYLF4+JwYQXv3OKRMCZPB4ZRopz4R17 eRUk0RPtVInpimxZ7QuqV+drTi+rEakDp8ww5PPO4NLQ0jV1lOsyD4iybNm4v46CEUm2 yA03O7uBOjQ9JnAdB0XcLBGmES2Zp8JpEoMqTKAaE+jbyepwC9qzR81Nwe2RvVWxhPI/ 2cEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZUiLChI8TlZJAnT7zw1vn7TLWt0FJRL6MChrvjmtE54=; b=iQGAVIuFf+z/OTdJt7uK3gKKNvWGXBsJcFBUgA6q3XJHnJkJEsEG7oxccbvQ9Nfp8H Ie9jEw6ltJk1ELQAn+QNd5Xjpxi2L//vtzLxcDvE8bd4d8b6S+L7fUzf6BOhUUw1wjKI Ayz8fIf3B7/69KnlZ0Iky9LkLCw4hmZ3bGYgcWrstZFkscR+vWnt+PUPU7z/f98aU70F JxQY9YagKxbjrZU7E+dMeGqWKxC8VoMpx4ttB0Or1qc+bNMzf7yXwjGxkQuUk5C3xpV3 JybEV1jK/T0xfqw6S3l6CVTqAXeeJ8BjV7e/hR1A526gkprQoG4+Y6ZxpT33tllv04AX PfCg== X-Gm-Message-State: AIkVDXKFoinzw5Zn/21uTaZkWngcSFzzRWbmU8lbUuTWAEb4YgffN3hSXQboIVyDKbnRShOXhw7fDO4u3Yec7Q== X-Received: by 10.200.56.76 with SMTP id r12mr35423342qtb.2.1484685184102; Tue, 17 Jan 2017 12:33:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.157.69 with HTTP; Tue, 17 Jan 2017 12:33:03 -0800 (PST) In-Reply-To: <20170117194651.GA88907@vlakno.cz> References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net> <20161205161904.GA7889@vlakno.cz> <20170117194651.GA88907@vlakno.cz> From: Justin Hibbits Date: Tue, 17 Jan 2017 14:33:03 -0600 Message-ID: Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . To: Roman Divacky Cc: FreeBSD Toolchain , Mark Millard , FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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 20:33:05 -0000 I was incorrect. The Freescale reference actually lists both numbers in the instruction list (167/231 in A.1 and A.5, 334/462 in A.2). The values you listed are correct, and match what GCC generates as well. - Justin On Jan 17, 2017 13:49, "Roman Divacky" wrote: > Are you sure? My coy of PowerISA lists the numbers that I used? What makes > you > think it should be shifted by one bit? > > On Mon, Jan 16, 2017 at 08:45:58PM -0600, Justin Hibbits wrote: > > The patch is incorrect, the 'xo' values are off by one bit (inline > > change): > > > > > > On Dec 5, 2016, at 10:19 AM, Roman Divacky wrote: > > > > > Can you try this patch? > > > > > > Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td > > > =================================================================== > > > --- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675) > > > +++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) > > > @@ -2373,6 +2373,12 @@ > > > def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), > > > "mftb $RT, $SPR", IIC_SprMFTB>; > > > > > > +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), > > > > 334 should be 167 > > > > > + "mfpmr $RT, $PMRN", IIC_IntGeneral>; > > > + > > > +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), > > > + "mtpmr $PMRN, $RS", IIC_IntGeneral>; > > > > 462 should be 231. > > > > > + > > > // A pseudo-instruction used to implement the read of the 64-bit > > > cycle counter > > > // on a 32-bit target. > > > let hasSideEffects = 1, usesCustomInserter = 1 in > > > > > > > I'll have a patch ready for LLVM review within a week or so, including > > some level of scheduling. > > > > - Justin > 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 From owner-freebsd-toolchain@freebsd.org Tue Jan 17 21:58:44 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 B8DAFCB4187 for ; Tue, 17 Jan 2017 21:58:44 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id 49F911753; Tue, 17 Jan 2017 21:58:43 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id 30C6E12CB9F; Tue, 17 Jan 2017 22:56:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1484690173; bh=YgEOUahFsxp37/1XIHUkewe3HbwHyb7x+GzkqPPT8fA=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=O+o8UYMMqJaCiVGS+j4OpiPIL94iune4db86ismlgay0pJRjj63ZIeoor42fejbF3 bTTsV8zz6SFJDew9NLUxUuWvvTQnLUHJII9cEKGKgUJt2EoeKEfS+VRSLRSmCYKvfk kbVmWAPR7lLDUXeEyrPWccDuk6OQMbO5FTDj2jMg= Date: Tue, 17 Jan 2017 22:56:13 +0100 From: Roman Divacky To: Mark Millard Cc: Ed Maste , FreeBSD Toolchain 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: <20170117215613.GA95258@vlakno.cz> References: <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> <237EB920-0795-4B18-94D4-2EAC0FC76F01@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <237EB920-0795-4B18-94D4-2EAC0FC76F01@dsl-only.net> User-Agent: Mutt/1.7.2 (2016-11-26) 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:58:44 -0000 Go with Out. On Tue, Jan 17, 2017 at 01:53:14PM -0800, Mark Millard wrote: > 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). > > > > LLD understands that we use GOT as TOC (which was true before my patch), > > I wonder if something like this: > > > > ndex: tools/lld/ELF/Target.cpp > > =================================================================== > > --- tools/lld/ELF/Target.cpp (revision 292071) > > +++ tools/lld/ELF/Target.cpp (working copy) > > @@ -1070,7 +1070,8 @@ > > } > > > > PPC64TargetInfo::PPC64TargetInfo() { > > - PltRel = GotRel = R_PPC64_GLOB_DAT; > > + GotRel = R_PPC64_GLOB_DAT; > > + PltRel = R_PPC64_JMP_SLOT; > > RelativeRel = R_PPC64_RELATIVE; > > GotEntrySize = 8; > > GotPltEntrySize = 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 = In::Got->getVA(); > > + uint64_t TocVA = In::Plt->getVA(); > > > > // 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 = Out::Got->getVA(); > > // 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 <<<<<===== NOTE!!!! > 0x0000000010020000 - 0x0000000010020010 is .ctors > 0x0000000010020010 - 0x0000000010020020 is .dtors > 0x0000000010020020 - 0x0000000010020028 is .jcr > 0x0000000010020028 - 0x0000000010020138 is .dynamic > 0x0000000010020138 - 0x0000000010020138 is .got <<<<<===== NOTE!!!! > 0x0000000010030000 - 0x0000000010030019 is .data > 0x0000000010030020 - 0x0000000010030050 is .got.plt <<<<<===== NOTE!!!! > 0x0000000010030050 - 0x00000000100300a0 is .toc <<<<<===== 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. > > === > Mark Millard > markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Tue Jan 17 23:06: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 D8014CB5298 for ; Tue, 17 Jan 2017 23:06:31 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DFE21FEC; Tue, 17 Jan 2017 23:06:31 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pg0-x22b.google.com with SMTP id t6so22866754pgt.3; Tue, 17 Jan 2017 15:06:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:date:message-id:cc:to:mime-version; bh=bF3sG4QQa6sSyaRNnOgPe2hXf6LXq4xRZ4x3U95IhwU=; b=Exi/yErXiRqD2edk4mv98iKkHlNAXutjLLneAOdW2rVSYpkBPn+ryK6CpmwMZGsQCU 4vI0VoqD+L4zDEYEwBNEqAfD3SSeyLtQprz8kzqWajq2I2qym7kRqeIAAhdhC5VzrezJ pRwGZPHj2OgcLB9irCsEmRd8Q5zWrcuhqm8jMd33ycPPh/ECUc04kgepf5R5bd82ltIS zapQYP4ITKzuob5XMedGMx1WjgQFqJwEZH5l8THPdz2vrQYjoRouV9xd0LMNzZze7ADd RgexywNNiWt/ISmesu+9q0muhpFcVBafTslRcZXVIVVCjzxAvJpMZtZfjvi0x+mC82bp 3evg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=bF3sG4QQa6sSyaRNnOgPe2hXf6LXq4xRZ4x3U95IhwU=; b=Oy6oDpHvZCyoWambrI6ug5KacUYoYVLaWzTInXper5+9UXhE6LwNAkb4OKdHc5KSMk IQ7vfiM8PkPCQvkptutTukCQ/WgXHqv4WCfZEkRMob2yj5sSWuNdPJKcROX+CLT6kbTA ujCAtX8MvTY2TMLFj/m0oWhTFOIc4FX452UISXuA6YKsJM6p7orQLvGZsI+eenWFzWrt RBiUJ+5/CaSj4iZGWO6jciLpY/Twb+vm4UewSIqisHn+A8T2DclQp906XSE4U6Ft3pfU blz5Xkvl5T24O4pKBgAVonk86dhbwCFJ4K1Z/ulGGMDnE2kUKgar9c4mkE3td4VEACnl XaTQ== X-Gm-Message-State: AIkVDXKPW8jspWVYNw9D5p9A6xmGRcOc/QYhM3vdvNB9SRibz9seD4dXvoLxwvVXeEzcgQ== X-Received: by 10.84.211.137 with SMTP id c9mr246436pli.8.1484694391152; Tue, 17 Jan 2017 15:06:31 -0800 (PST) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id q2sm58562467pga.8.2017.01.17.15.06.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 17 Jan 2017 15:06:30 -0800 (PST) From: "Ngie Cooper (yaneurabeya)" X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_F0DF2B77-B756-423D-ACE3-F0BC80054E2D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: elfdump doesn't support .a files? Date: Tue, 17 Jan 2017 15:06:29 -0800 Message-Id: <47D8BA32-68B5-411C-A621-7AAE55A087D0@gmail.com> To: FreeBSD Toolchain Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) 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 23:06:32 -0000 --Apple-Mail=_F0DF2B77-B756-423D-ACE3-F0BC80054E2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ed, I tried running elfdump on a .a archive and it seems that = elfdump doesn=E2=80=99t support this (whereas objdump does). Is this = expected? Thanks! -Ngie --Apple-Mail=_F0DF2B77-B756-423D-ACE3-F0BC80054E2D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYfqN2AAoJEPWDqSZpMIYV/LsP/1Q2NiQmhufhxo4fxYZWuf1g bGvXqJitkbeh6rTWHPSKesCmfvMUF4CJV8BHTcL8h+X9kkeD1VRcbCkIn3+38cT2 IOAj822/h6d1C99kw1QsLAzYGx2yR7XKxu56kRJQlXh6tewGJqveVfN6vA+2In3Q IW5FZonUcSgSTURSEsg9mkwFYGq25kY8ZSkPBUpKlmluBzCcyu7nKUes3YffPOay wCyVq1ZvfKHtBSb7La3n/+0toSv/UFLIp7TFRaPcXZTQjcWfL+dvH6DHyHOffsrH TRYVywlicagfv4AKcEwH/Iy8uEDZno81UKacYN5vfMbPYVFHoKGjvg8Lg8nTDhvj /rQkNPfqGDQs9cWb0sly713Gthlfe2epEPXzWICN8abCcSJK6Jkos9F4y2Fo3lMp o7vlPU02cKIL8f0tcNeXUpwM3bJpA2cpM9IfkWWtiulqm7IBz0DTZ/0kWKHKHgYl LpnvpNH3PZ+abDotA047TqzTtzz6l53EvObm7a5WFnv0YtN2QNApD9ksQbbfoEjt +HhtqPtr965en5iFrzbiATDCRhjAd6rWejVM8/shTs0YXR41coRKwVQpHJqP5dXJ N2THRU83qGXizXKu++kJBxss3X1C06bXl6+FdKcpZRemrylkFbwUUAlfB+68HVfy p17TXxctXRJc22g9GaiC =r+Bu -----END PGP SIGNATURE----- --Apple-Mail=_F0DF2B77-B756-423D-ACE3-F0BC80054E2D-- From owner-freebsd-toolchain@freebsd.org Wed Jan 18 05:38:16 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 A4030CB32C6 for ; Wed, 18 Jan 2017 05:38:16 +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 65A1A1BDC for ; Wed, 18 Jan 2017 05:38:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32723 invoked from network); 18 Jan 2017 05:38:09 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 18 Jan 2017 05:38:09 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Wed, 18 Jan 2017 00:38:09 -0500 (EST) Received: (qmail 14559 invoked from network); 18 Jan 2017 05:38:08 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 18 Jan 2017 05:38:08 -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 D2BAAEC9202; Tue, 17 Jan 2017 21:38:07 -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: <20170117215613.GA95258@vlakno.cz> Date: Tue, 17 Jan 2017 21:38:07 -0800 Cc: Ed Maste , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <45D0BB1C-490A-4809-BAB1-F4E552FECEDD@dsl-only.net> References: <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> <237EB920-0795-4B18-94D4-2EAC0FC76F01@dsl-only.net> <20170117215613.GA95258@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: Wed, 18 Jan 2017 05:38:16 -0000 Using the new changed line (Plt use now): uint64_t TocVA =3D Out::Plt->getVA(); 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. [I've no clue if this is what you expected from the Plt experiment or not.] Details. . . # /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 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, = lockstate=3D) at /usr/src/libexec/rtld-elf/rtld.c:2541 #3 0x0000000050029fa8 in _rtld (sp=3D, = exit_proc=3D, objp=3D) 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 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 =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-17, at 1:56 PM, Roman Divacky wrote: > 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 = 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::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 >>=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::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 From owner-freebsd-toolchain@freebsd.org Wed Jan 18 12:00:56 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 9DDA9CB5A8C for ; Wed, 18 Jan 2017 12:00:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-16.reflexion.net [208.70.210.16]) (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 4FFB01393 for ; Wed, 18 Jan 2017 12:00:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8206 invoked from network); 18 Jan 2017 12:01:16 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 18 Jan 2017 12:01:16 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Wed, 18 Jan 2017 07:00:49 -0500 (EST) Received: (qmail 22378 invoked from network); 18 Jan 2017 12:00:49 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 18 Jan 2017 12:00:49 -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 9BDCCEC9092; Wed, 18 Jan 2017 04:00:48 -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: Bug 216229 - head: (e.g. -r312009): kernel-toolchain: bootstrap-tools stage libllvmminimal can fail for lack of -I options Message-Id: <395F73EA-4544-4239-861F-7EF8386A419D@dsl-only.net> Date: Wed, 18 Jan 2017 04:00:47 -0800 To: FreeBSD Toolchain , FreeBSD PowerPC ML 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: Wed, 18 Jan 2017 12:00:56 -0000 I have reported the following as bugzilla 216229. . . [powerpc64 may not be essential but it is the environment I found this in.] Background information: libllvmminimal has C++ code, not (just) C code. [Note that CFLAGS has things like -std=3Dgnu99 that are not appropriate = to c++ (clang++).] So the lines from /usr/src/lib/clang/llvm.build.mk for CFLAGS: CFLAGS+=3D -I${SRCTOP}/lib/clang/include CFLAGS+=3D -I${LLVM_SRCS}/include CFLAGS+=3D -DLLVM_ON_UNIX CFLAGS+=3D -DLLVM_ON_FREEBSD CFLAGS+=3D -D__STDC_LIMIT_MACROS CFLAGS+=3D -D__STDC_CONSTANT_MACROS #CFLAGS+=3D -DNDEBUG . . . CFLAGS+=3D -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"${TARGET_TRIPLE}\" CFLAGS+=3D -DLLVM_HOST_TRIPLE=3D\"${BUILD_TRIPLE}\" CFLAGS+=3D -DDEFAULT_SYSROOT=3D\"${TOOLS_PREFIX}\" do not contribute to the C++ compiles for libllvmminimal. (See the later meta file content from such a failure: no -I options at all.) Thus unless the system compiler is in use so that no bootstrap compiler is to be built. . . The lack of -I definitions for C++ ends up with build failures such as below (from a first-time kernel-toolchain example): (this was a on-powerpc64, targeting powerpc64, example, not a cross-build) # Meta data file = /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/= tmp/usr/src/lib/clang/libllvmminimal/_usr_obj_powerpc64vtsc_clang_altbinut= ils_kernel_powerpc.powerpc64_usr_src_tmp_usr_src_lib_clang_libllvmminimal_= Support_APInt.o.meta CMD clang++ -B/usr/local/powerpc64-freebsd/bin/ -std=3Dc++11 = -fno-exceptions -fno-rtti -stdlib=3Dlibc++ -Wno-c++11-extensions -c = /usr/src/contrib/llvm/lib/Support/APInt.cpp -o Support/APInt.o CWD = /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/= tmp/usr/src/lib/clang/libllvmminimal TARGET Support/APInt.o -- command output -- /usr/src/contrib/llvm/lib/Support/APInt.cpp:15:10: fatal error: = 'llvm/ADT/APInt.h' file not found #include "llvm/ADT/APInt.h" ^ 1 error generated. *** Error code 1 libllvmminimal is not necessarily the only problem but it is the first = one and it is very early (bootstrap-tools stage). -I is not necessarily the only compile option type that is missing for libllvmminimal. [Note: I've a couple of poudriere-devel submittals that may actually = trace back to such issues --so poudriere might not be essential to the actual = issue.] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Wed Jan 18 21:56:57 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 C58E9CB6F2C for ; Wed, 18 Jan 2017 21:56:57 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id 2FC76114F; Wed, 18 Jan 2017 21:56:56 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id 8D32812CA54; Wed, 18 Jan 2017 22:54:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1484776460; bh=e5lS0APQvI97eVO0PhEE3bkn6TNXmVjASFHyIkTPim4=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=LGfJyX1zT+XW8EgLtcLp8Yg4BWTdv2GofEa7J/LT2mgzhHGNRLsmLxWgHFGlYEiEF ASdd3REy4wsxQ6GRPUMomV/TEydmWSHe7koQ2ldG4ar2LLfnaOpUMxetoMPHBa0/fC XiIjZeBWmOuuVnVKbJceEbJMokniNdzm+prrAW44= Date: Wed, 18 Jan 2017 22:54:20 +0100 From: Roman Divacky To: Mark Millard Cc: Ed Maste , FreeBSD Toolchain 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: <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> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45D0BB1C-490A-4809-BAB1-F4E552FECEDD@dsl-only.net> User-Agent: Mutt/1.7.2 (2016-11-26) 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: Wed, 18 Jan 2017 21:56:57 -0000 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. For some reason, GOT is empty, in our case. I believe this might be caused by a relocation thats wrongly mapped to R_ABS in PPC64TargetInfo::getRelExpr(). 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? Thanks Index: ../tools/lld/ELF/Target.cpp =================================================================== --- ../tools/lld/ELF/Target.cpp (revision 292428) +++ ../tools/lld/ELF/Target.cpp (working copy) @@ -1075,7 +1075,8 @@ } PPC64TargetInfo::PPC64TargetInfo() { - PltRel = GotRel = R_PPC64_GLOB_DAT; + GotRel = R_PPC64_GLOB_DAT; + PltRel = R_PPC64_JMP_SLOT; RelativeRel = R_PPC64_RELATIVE; GotEntrySize = 8; GotPltEntrySize = 8; @@ -1114,8 +1115,10 @@ } RelExpr PPC64TargetInfo::getRelExpr(uint32_t Type, const SymbolBody &S) const { + llvm::outs() << "Type = " << Type << ", name = " << S.getName() << "\n"; switch (Type) { default: + llvm::outs() << "Unhandled type = " << Type << "\n"; return R_ABS; case R_PPC64_TOC16: case R_PPC64_TOC16_DS: On Tue, Jan 17, 2017 at 09:38:07PM -0800, Mark Millard wrote: > Using the new changed line (Plt use now): > > uint64_t TocVA = Out::Plt->getVA(); > > changed the behavior and it gets farther for > -fuse-ld=lld 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==0x10018560 initially in __do_global_ctors_aux > seems wrong. If so then objlist_call_init produced > a wrong r2 value. > > [I've no clue if this is what you expected from > the Plt experiment or not.] > > Details. . . > > # /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 > > 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=, lockstate=) at /usr/src/libexec/rtld-elf/rtld.c:2541 > #3 0x0000000050029fa8 in _rtld (sp=, exit_proc=, objp=) 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 <<<<<==== 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 > => 0x00000000100104a8 <+56>: ld r4,8(r3) <<<<<==== 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 <<<<<==== 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 > 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 > > > === > Mark Millard > markmi at dsl-only.net > > On 2017-Jan-17, at 1:56 PM, Roman Divacky wrote: > > > Go with Out. > > > > On Tue, Jan 17, 2017 at 01:53:14PM -0800, Mark Millard wrote: > >> 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). > >>> > >>> LLD understands that we use GOT as TOC (which was true before my patch), > >>> I wonder if something like this: > >>> > >>> ndex: tools/lld/ELF/Target.cpp > >>> =================================================================== > >>> --- tools/lld/ELF/Target.cpp (revision 292071) > >>> +++ tools/lld/ELF/Target.cpp (working copy) > >>> @@ -1070,7 +1070,8 @@ > >>> } > >>> > >>> PPC64TargetInfo::PPC64TargetInfo() { > >>> - PltRel = GotRel = R_PPC64_GLOB_DAT; > >>> + GotRel = R_PPC64_GLOB_DAT; > >>> + PltRel = R_PPC64_JMP_SLOT; > >>> RelativeRel = R_PPC64_RELATIVE; > >>> GotEntrySize = 8; > >>> GotPltEntrySize = 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 = In::Got->getVA(); > >>> + uint64_t TocVA = In::Plt->getVA(); > >>> > >>> // 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 = Out::Got->getVA(); > >> > >> // 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 <<<<<===== NOTE!!!! > >> 0x0000000010020000 - 0x0000000010020010 is .ctors > >> 0x0000000010020010 - 0x0000000010020020 is .dtors > >> 0x0000000010020020 - 0x0000000010020028 is .jcr > >> 0x0000000010020028 - 0x0000000010020138 is .dynamic > >> 0x0000000010020138 - 0x0000000010020138 is .got <<<<<===== NOTE!!!! > >> 0x0000000010030000 - 0x0000000010030019 is .data > >> 0x0000000010030020 - 0x0000000010030050 is .got.plt <<<<<===== NOTE!!!! > >> 0x0000000010030050 - 0x00000000100300a0 is .toc <<<<<===== 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. > >> > >> === > >> Mark Millard > >> markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Wed Jan 18 23:41:53 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 D131CCB54C1 for ; Wed, 18 Jan 2017 23:41:53 +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 936B911FD for ; Wed, 18 Jan 2017 23:41:52 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 903 invoked from network); 18 Jan 2017 23:41:51 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 18 Jan 2017 23:41:51 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Wed, 18 Jan 2017 18:41:51 -0500 (EST) Received: (qmail 27301 invoked from network); 18 Jan 2017 23:41:51 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 18 Jan 2017 23:41:51 -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 CCA89EC9092; Wed, 18 Jan 2017 15:41:50 -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: <20170118215420.GA65399@vlakno.cz> Date: Wed, 18 Jan 2017 15:41:50 -0800 Cc: Ed Maste , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <9023794B-0999-4F50-95DE-2D4156BC6E75@dsl-only.net> 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> <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> 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: Wed, 18 Jan 2017 23:41:53 -0000 On 2017-Jan-18, at 1:54 PM, Roman Divacky 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::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, = lockstate=3D) at /usr/src/libexec/rtld-elf/rtld.c:2541 > #3 0x0000000050029fa8 in _rtld (sp=3D, = exit_proc=3D, objp=3D) 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 > 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 = 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 = 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::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 >>>=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::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 From owner-freebsd-toolchain@freebsd.org Thu Jan 19 01:37:36 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 0C941CB6D89 for ; Thu, 19 Jan 2017 01:37:36 +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 C06301C32 for ; Thu, 19 Jan 2017 01:37:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12004 invoked from network); 19 Jan 2017 01:37:55 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 19 Jan 2017 01:37:55 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Wed, 18 Jan 2017 20:37:28 -0500 (EST) Received: (qmail 2221 invoked from network); 19 Jan 2017 01:37:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 19 Jan 2017 01:37:27 -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 071C2EC8F7B; Wed, 18 Jan 2017 17:37:27 -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: <9023794B-0999-4F50-95DE-2D4156BC6E75@dsl-only.net> Date: Wed, 18 Jan 2017 17:37:26 -0800 Cc: Ed Maste , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: 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> <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> <9023794B-0999-4F50-95DE-2D4156BC6E75@dsl-only.net> 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: Thu, 19 Jan 2017 01:37:36 -0000 Well trying to have the global variable in various forms produced more information when I tried having it in a shared object: (This was before your changes to add log messages.) # more gblvar.c volatile long gblvar =3D 1; # clang -g -fuse-ld=3Dlld -shared -o gblvar.so gblvar.c can't create dynamic relocation R_PPC64_REL24 against readonly segment can't create dynamic relocation R_PPC64_REL24 against readonly segment can't create dynamic relocation R_PPC64_REL24 against readonly segment clang: error: linker command failed with exit code 1 (use -v to see = invocation) By contrast: # clang -g -fuse-ld=3Dbfd -shared -o gblvar.so gblvar.c #=20 (so no problem reported). =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-18, at 3:41 PM, Mark Millard wrote: On 2017-Jan-18, at 1:54 PM, Roman Divacky 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::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, = lockstate=3D) at /usr/src/libexec/rtld-elf/rtld.c:2541 > #3 0x0000000050029fa8 in _rtld (sp=3D, = exit_proc=3D, objp=3D) 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 > 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 = 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 = 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::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 >>>=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::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 _______________________________________________ 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" From owner-freebsd-toolchain@freebsd.org Thu Jan 19 06:48:32 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 67053CB7EFC for ; Thu, 19 Jan 2017 06:48:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-16.reflexion.net [208.70.210.16]) (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 2840F119E for ; Thu, 19 Jan 2017 06:48:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9061 invoked from network); 19 Jan 2017 06:50:04 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 19 Jan 2017 06:50:04 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Thu, 19 Jan 2017 01:48:30 -0500 (EST) Received: (qmail 29102 invoked from network); 19 Jan 2017 06:48:30 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 19 Jan 2017 06:48:30 -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 AD01AEC7D48; Wed, 18 Jan 2017 22:48:29 -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: Date: Wed, 18 Jan 2017 22:48:28 -0800 Cc: FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <545CE5A1-9E7F-46C0-8355-0C32B60D1C72@dsl-only.net> 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> <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> <9023794B-0999-4F50-95DE-2D4156BC6E75@dsl-only.net> 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: Thu, 19 Jan 2017 06:48:32 -0000 The log messages code does not work because of Assertion failures: # clang -fuse-ld=3Dlld -g main.c Type =3D 50, name =3D Assertion failed: (!isLocal()), function getName, = file /usr/src/contrib/llvm/tools/lld/ELF/Symbols.cpp, line 100. clang: error: unable to execute command: Abort trap (core dumped) clang: error: linker command failed due to signal (use -v to see = invocation) So for now I've disabled the name part of the line. At least we will see the numeric type of each and the reports of any "unhandled" values. I decided to use the Got variation instead of the Plt variant first. Some examples: # more empty_src.c # clang -fuse-ld=3Dlld -g -shared -o empty_src.so empty_src.c Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 10 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 10 can't create dynamic relocation R_PPC64_REL24 against readonly segment Type =3D 10 can't create dynamic relocation R_PPC64_REL24 against readonly segment Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 48 Type =3D 10 can't create dynamic relocation R_PPC64_REL24 against readonly segment Type =3D 38 Unhandled type =3D 38 Type =3D 51 clang: error: linker command failed with exit code 1 (use -v to see = invocation) # clang -fuse-ld=3Dlld -g empty_src.c Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 10 Type =3D 10 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 10 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 10 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 10 Type =3D 10 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 10 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 10 Type =3D 10 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 48 Type =3D 10 Type =3D 38 Unhandled type =3D 38 Type =3D 51 undefined symbol: main in /usr/lib/crt1.o clang: error: linker command failed with exit code 1 (use -v to see = invocation) # more main.c volatile void* gblvar =3D 0; int main () { gblvar =3D &gblvar; } # clang -fuse-ld=3Dlld -g main.c Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 10 Type =3D 10 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 10 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 10 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 10 Type =3D 10 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 10 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 10 Type =3D 10 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 50 Type =3D 48 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 48 Type =3D 10 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 1 Unhandled type =3D 1 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 # more main.c int main () { } # clang -fuse-ld=3Dlld -g main.c Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 10 Type =3D 10 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 10 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 10 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 10 Type =3D 10 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 10 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 10 Type =3D 10 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 48 Type =3D 10 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-18, at 3:41 PM, Mark Millard wrote: On 2017-Jan-18, at 1:54 PM, Roman Divacky 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::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, = lockstate=3D) at /usr/src/libexec/rtld-elf/rtld.c:2541 > #3 0x0000000050029fa8 in _rtld (sp=3D, = exit_proc=3D, objp=3D) 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 > 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 = 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 = 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::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 >>>=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::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 _______________________________________________ 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" _______________________________________________ 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" From owner-freebsd-toolchain@freebsd.org Thu Jan 19 09:46:06 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 E8F0ECB55BD for ; Thu, 19 Jan 2017 09:46:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-16.reflexion.net [208.70.210.16]) (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 A9C121CAF for ; Thu, 19 Jan 2017 09:46:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5509 invoked from network); 19 Jan 2017 09:46:04 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 19 Jan 2017 09:46:04 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Thu, 19 Jan 2017 04:46:04 -0500 (EST) Received: (qmail 31700 invoked from network); 19 Jan 2017 09:46:04 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 19 Jan 2017 09:46:04 -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 AA839EC7D48; Thu, 19 Jan 2017 01:46:03 -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: <545CE5A1-9E7F-46C0-8355-0C32B60D1C72@dsl-only.net> Date: Thu, 19 Jan 2017 01:46:02 -0800 Cc: FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <278EB6CA-6A04-43D6-A9F2-84FF11A367C7@dsl-only.net> 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> <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> <9023794B-0999-4F50-95DE-2D4156BC6E75@dsl-only.net> <545CE5A1-9E7F-46C0-8355-0C32B60D1C72@dsl-only.net> 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: Thu, 19 Jan 2017 09:46:07 -0000 I should have noted that -pie gets the same sort of readonly segment errors as -shared did: # clang -fuse-ld=3Dlld -g -pie empty_src.c Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 10 Type =3D 10 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 10 Type =3D 50 Type =3D 50 Type =3D 48 Type =3D 48 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 50 Type =3D 48 Type =3D 48 Type =3D 50 Type =3D 50 Type =3D 48 Type =3D 48 Type =3D 10 can't create dynamic relocation R_PPC64_REL24 against readonly segment Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 50 Type =3D 48 Type =3D 48 Type =3D 10 can't create dynamic relocation R_PPC64_REL24 against readonly segment Type =3D 10 Type =3D 50 Type =3D 50 Type =3D 48 Type =3D 48 Type =3D 50 Type =3D 50 Type =3D 48 Type =3D 48 Type =3D 10 can't create dynamic relocation R_PPC64_REL24 against readonly segment Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 10 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 10 can't create dynamic relocation R_PPC64_REL24 against readonly segment Type =3D 10 can't create dynamic relocation R_PPC64_REL24 against readonly segment Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 48 Type =3D 10 can't create dynamic relocation R_PPC64_REL24 against readonly segment Type =3D 38 Unhandled type =3D 38 Type =3D 51 undefined symbol: main in /usr/lib/Scrt1.o clang: error: linker command failed with exit code 1 (use -v to see = invocation) # more main.c int main () { } # clang -fuse-ld=3Dlld -g -pie main.c Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 10 Type =3D 10 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 10 Type =3D 50 Type =3D 50 Type =3D 48 Type =3D 48 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 50 Type =3D 48 Type =3D 48 Type =3D 50 Type =3D 50 Type =3D 48 Type =3D 48 Type =3D 10 can't create dynamic relocation R_PPC64_REL24 against readonly segment Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 50 Type =3D 48 Type =3D 48 Type =3D 10 can't create dynamic relocation R_PPC64_REL24 against readonly segment Type =3D 10 Type =3D 50 Type =3D 50 Type =3D 48 Type =3D 48 Type =3D 50 Type =3D 50 Type =3D 48 Type =3D 48 Type =3D 10 can't create dynamic relocation R_PPC64_REL24 against readonly segment Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 10 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 10 can't create dynamic relocation R_PPC64_REL24 against readonly segment Type =3D 10 can't create dynamic relocation R_PPC64_REL24 against readonly segment Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 48 Type =3D 10 can't create dynamic relocation R_PPC64_REL24 against readonly segment Type =3D 38 Unhandled type =3D 38 Type =3D 51 clang: error: linker command failed with exit code 1 (use -v to see = invocation) So making something with a relocatable global variable is problematical via lld. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-18, at 10:48 PM, Mark Millard = wrote: The log messages code does not work because of Assertion failures: # clang -fuse-ld=3Dlld -g main.c Type =3D 50, name =3D Assertion failed: (!isLocal()), function getName, = file /usr/src/contrib/llvm/tools/lld/ELF/Symbols.cpp, line 100. clang: error: unable to execute command: Abort trap (core dumped) clang: error: linker command failed due to signal (use -v to see = invocation) So for now I've disabled the name part of the line. At least we will see the numeric type of each and the reports of any "unhandled" values. I decided to use the Got variation instead of the Plt variant first. Some examples: # more empty_src.c # clang -fuse-ld=3Dlld -g -shared -o empty_src.so empty_src.c Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 10 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 10 can't create dynamic relocation R_PPC64_REL24 against readonly segment Type =3D 10 can't create dynamic relocation R_PPC64_REL24 against readonly segment Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 48 Type =3D 10 can't create dynamic relocation R_PPC64_REL24 against readonly segment Type =3D 38 Unhandled type =3D 38 Type =3D 51 clang: error: linker command failed with exit code 1 (use -v to see = invocation) # clang -fuse-ld=3Dlld -g empty_src.c Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 10 Type =3D 10 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 10 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 10 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 10 Type =3D 10 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 10 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 10 Type =3D 10 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 48 Type =3D 10 Type =3D 38 Unhandled type =3D 38 Type =3D 51 undefined symbol: main in /usr/lib/crt1.o clang: error: linker command failed with exit code 1 (use -v to see = invocation) # more main.c volatile void* gblvar =3D 0; int main () { gblvar =3D &gblvar; } # clang -fuse-ld=3Dlld -g main.c Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 10 Type =3D 10 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 10 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 10 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 10 Type =3D 10 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 10 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 10 Type =3D 10 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 50 Type =3D 48 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 48 Type =3D 10 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 1 Unhandled type =3D 1 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 # more main.c int main () { } # clang -fuse-ld=3Dlld -g main.c Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 10 Type =3D 10 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 10 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 10 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 10 Type =3D 10 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 10 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 64 Type =3D 50 Type =3D 48 Type =3D 10 Type =3D 10 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 50 Type =3D 48 Type =3D 50 Type =3D 48 Type =3D 10 Type =3D 38 Unhandled type =3D 38 Type =3D 51 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 1 Unhandled type =3D 1 Type =3D 38 Unhandled type =3D 38 Type =3D 38 Unhandled type =3D 38 =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-18, at 3:41 PM, Mark Millard wrote: On 2017-Jan-18, at 1:54 PM, Roman Divacky 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::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, = lockstate=3D) at /usr/src/libexec/rtld-elf/rtld.c:2541 > #3 0x0000000050029fa8 in _rtld (sp=3D, = exit_proc=3D, objp=3D) 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 > 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 = 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 = 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::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 >>>=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::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 _______________________________________________ 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" _______________________________________________ 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" _______________________________________________ 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" From owner-freebsd-toolchain@freebsd.org Thu Jan 19 17:26:51 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 E048CCB5565 for ; Thu, 19 Jan 2017 17:26:51 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B598F119A for ; Thu, 19 Jan 2017 17:26:51 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x229.google.com with SMTP id 203so1777464ith.0 for ; Thu, 19 Jan 2017 09:26:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=sbxWY0rT9tEeG3JqhEXxhsm4AatGPY9x2j4RDFaUw3M=; b=aNGSFym+OZfcp/dhcpXqER3qA/f5ul3Pbl1ao8lk6jX54+uE7YiXj7d9LjH3zidP+J cg/mUDx95qelUhJA/vqTXhJIAV4lQ32OXBsel3davVHznsbm3Fc0eyd7rWlfnUR/uaEa +99yo27j2rmfmESBZpQB2C0NsV1e+VK981vr/WQT78Rj4xAPRM5uBPett/ij4iXH7r0W CnZXcRBm68zgxv3InF7Gfk80s5ZhmYamkaf6oF7AZyYoyYSUHsmIA//TTTyQArOzjXF1 pMLLCqrm6SHpV76gPFl96meIYEVhySisiUZRprHsVdtBv5u2IWHzSxs+r2M7yunGXWDy nzsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=sbxWY0rT9tEeG3JqhEXxhsm4AatGPY9x2j4RDFaUw3M=; b=qiGv7hG3HE9FeqQoUCXiJxDd/Qr2uhSbkvKcjEshUKNiQfIkP9zK1JJOdiJ2uGY+Bm bm/XTeJ/TuTzZoPgRb24AtG2CrLkMikeD2WRIeufPdkGqMy8R/nR5pFyfrRjrw4XhbvW z5cmlK4py7Uomia4T/Id+JTbYPuNde6eyqgu4vZbZHPzKkSfiqFzKBbTQCIVvKZ4X/If VjHWW42FAi+9jbDkycd6402g3sUJ8cqyCh6Bl1VCfQsHfx3MglLPiayYeXNbF5sLQFrH sK6B6VesQcWXOEDu+BcezXkSeKIubO9AAc8jJocRPFDK78TpLHuQbRzX+IxRN8Nhu1yV H+Yg== X-Gm-Message-State: AIkVDXKCp7ZdSA8eRnXW/zpKbPiotq9gllj4mkBu8YKyFrXLWXSUQxjRn6csjDyT4WgYJq3wkygnagfB/wayWw== X-Received: by 10.36.86.4 with SMTP id o4mr31610266itb.83.1484846811110; Thu, 19 Jan 2017 09:26:51 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.175.159 with HTTP; Thu, 19 Jan 2017 09:26:30 -0800 (PST) In-Reply-To: <47D8BA32-68B5-411C-A621-7AAE55A087D0@gmail.com> References: <47D8BA32-68B5-411C-A621-7AAE55A087D0@gmail.com> From: Ed Maste Date: Thu, 19 Jan 2017 12:26:30 -0500 X-Google-Sender-Auth: uyoCAAi0jhJW70u3F1wx7rwWJ_o Message-ID: Subject: Re: elfdump doesn't support .a files? To: "Ngie Cooper (yaneurabeya)" Cc: FreeBSD Toolchain Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Thu, 19 Jan 2017 17:26:52 -0000 On 17 January 2017 at 18:06, Ngie Cooper (yaneurabeya) wrote: > Hi Ed, > I tried running elfdump on a .a archive and it seems that elfdump= doesn=E2=80=99t support this (whereas objdump does). Is this expected? Indeed it does not. We're still using FreeBSD's original elfdump. The ELF Tool Chain project (which provides the objcopy, size, strings etc. that we use) also imported FreeBSD's elfdump and made some enhancements, including the ability to handle .a files. Unfortunately there are a few changes which exist in FreeBSD's elfdump but not ELF Tool Chain's version. We need to port those from FreeBSD to ELF Tool Chain before we can migrate to ELF Tool Chain's elfdump. From owner-freebsd-toolchain@freebsd.org Thu Jan 19 20:08:02 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 42266CB8D07 for ; Thu, 19 Jan 2017 20:08:02 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id B160612C3 for ; Thu, 19 Jan 2017 20:08:01 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id A6BAF12CA24; Thu, 19 Jan 2017 21:05:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1484856330; bh=VxHfulrjnxXfLZjF7j7OFFdsvPIOk0dsTE0uee8KLN0=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=H130hojdqXNMDZBB/GRwHNoi5dhz2gWjLU+mWY97WvOjU2wbj/Z028Zm59wWtduFY bk5TzElGXzxiCk+0eelbV/KkL2PpYPP905kXRKGGe2DthWvoePp/5xK4NoDqmFBBFh 5SRWqy+i++6J+O0+Qt56ruCH02vCI9SGMJnZ1yNo= Date: Thu, 19 Jan 2017 21:05:30 +0100 From: Roman Divacky To: Mark Millard Cc: FreeBSD Toolchain 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: <20170119200530.GA58089@vlakno.cz> References: <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> <9023794B-0999-4F50-95DE-2D4156BC6E75@dsl-only.net> <545CE5A1-9E7F-46C0-8355-0C32B60D1C72@dsl-only.net> <278EB6CA-6A04-43D6-A9F2-84FF11A367C7@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <278EB6CA-6A04-43D6-A9F2-84FF11A367C7@dsl-only.net> User-Agent: Mutt/1.7.2 (2016-11-26) 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: Thu, 19 Jan 2017 20:08:02 -0000 Type = 38 should be R_ABS so thats fine. If what I expected to be in .got is in .got.plt, what happens if you modify the getPPC64TocBase() to use ::GotPlt instead of ::Got ? On Thu, Jan 19, 2017 at 01:46:02AM -0800, Mark Millard wrote: > I should have noted that -pie gets the same sort of > readonly segment errors as -shared did: > > # clang -fuse-ld=lld -g -pie empty_src.c > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 10 > Type = 10 > Type = 50 > Type = 64 > Type = 50 > Type = 48 > Type = 10 > Type = 50 > Type = 50 > Type = 48 > Type = 48 > Type = 50 > Type = 48 > Type = 50 > Type = 50 > Type = 48 > Type = 48 > Type = 50 > Type = 50 > Type = 48 > Type = 48 > Type = 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type = 50 > Type = 48 > Type = 50 > Type = 50 > Type = 48 > Type = 48 > Type = 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type = 10 > Type = 50 > Type = 50 > Type = 48 > Type = 48 > Type = 50 > Type = 50 > Type = 48 > Type = 48 > Type = 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 50 > Type = 48 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 10 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 64 > Type = 50 > Type = 48 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 50 > Type = 48 > Type = 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type = 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 50 > Type = 48 > Type = 50 > Type = 48 > Type = 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type = 38 > Unhandled type = 38 > Type = 51 > undefined symbol: main in /usr/lib/Scrt1.o > clang: error: linker command failed with exit code 1 (use -v to see invocation) > > # more main.c > int main () > { > } > # clang -fuse-ld=lld -g -pie main.c > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 10 > Type = 10 > Type = 50 > Type = 64 > Type = 50 > Type = 48 > Type = 10 > Type = 50 > Type = 50 > Type = 48 > Type = 48 > Type = 50 > Type = 48 > Type = 50 > Type = 50 > Type = 48 > Type = 48 > Type = 50 > Type = 50 > Type = 48 > Type = 48 > Type = 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type = 50 > Type = 48 > Type = 50 > Type = 50 > Type = 48 > Type = 48 > Type = 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type = 10 > Type = 50 > Type = 50 > Type = 48 > Type = 48 > Type = 50 > Type = 50 > Type = 48 > Type = 48 > Type = 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 50 > Type = 48 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 10 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 64 > Type = 50 > Type = 48 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 50 > Type = 48 > Type = 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type = 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 50 > Type = 48 > Type = 50 > Type = 48 > Type = 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type = 38 > Unhandled type = 38 > Type = 51 > clang: error: linker command failed with exit code 1 (use -v to see invocation) > > > So making something with a relocatable global variable is problematical > via lld. > > === > Mark Millard > markmi at dsl-only.net > > On 2017-Jan-18, at 10:48 PM, Mark Millard wrote: > > The log messages code does not work because of Assertion failures: > > # clang -fuse-ld=lld -g main.c > Type = 50, name = Assertion failed: (!isLocal()), function getName, file /usr/src/contrib/llvm/tools/lld/ELF/Symbols.cpp, line 100. > clang: error: unable to execute command: Abort trap (core dumped) > clang: error: linker command failed due to signal (use -v to see invocation) > > So for now I've disabled the name part of the line. At least we will > see the numeric type of each and the reports of any "unhandled" values. > > I decided to use the Got variation instead of the Plt variant first. > > Some examples: > > # more empty_src.c > > # clang -fuse-ld=lld -g -shared -o empty_src.so empty_src.c > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 50 > Type = 48 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 10 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 64 > Type = 50 > Type = 48 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 50 > Type = 48 > Type = 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type = 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 50 > Type = 48 > Type = 50 > Type = 48 > Type = 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type = 38 > Unhandled type = 38 > Type = 51 > clang: error: linker command failed with exit code 1 (use -v to see invocation) > > # clang -fuse-ld=lld -g empty_src.c > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 50 > Type = 48 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 10 > Type = 10 > Type = 50 > Type = 64 > Type = 50 > Type = 48 > Type = 10 > Type = 50 > Type = 50 > Type = 64 > Type = 64 > Type = 50 > Type = 64 > Type = 50 > Type = 50 > Type = 64 > Type = 64 > Type = 50 > Type = 50 > Type = 64 > Type = 64 > Type = 10 > Type = 50 > Type = 64 > Type = 50 > Type = 50 > Type = 64 > Type = 64 > Type = 10 > Type = 10 > Type = 50 > Type = 50 > Type = 64 > Type = 64 > Type = 50 > Type = 50 > Type = 64 > Type = 64 > Type = 10 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 50 > Type = 48 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 64 > Type = 50 > Type = 48 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 50 > Type = 48 > Type = 10 > Type = 10 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 50 > Type = 48 > Type = 50 > Type = 48 > Type = 10 > Type = 38 > Unhandled type = 38 > Type = 51 > undefined symbol: main in /usr/lib/crt1.o > clang: error: linker command failed with exit code 1 (use -v to see invocation) > > # more main.c > volatile void* gblvar = 0; > > int main () > { > gblvar = &gblvar; > } > > # clang -fuse-ld=lld -g main.c > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 50 > Type = 48 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 10 > Type = 10 > Type = 50 > Type = 64 > Type = 50 > Type = 48 > Type = 10 > Type = 50 > Type = 50 > Type = 64 > Type = 64 > Type = 50 > Type = 64 > Type = 50 > Type = 50 > Type = 64 > Type = 64 > Type = 50 > Type = 50 > Type = 64 > Type = 64 > Type = 10 > Type = 50 > Type = 64 > Type = 50 > Type = 50 > Type = 64 > Type = 64 > Type = 10 > Type = 10 > Type = 50 > Type = 50 > Type = 64 > Type = 64 > Type = 50 > Type = 50 > Type = 64 > Type = 64 > Type = 10 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 50 > Type = 48 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 64 > Type = 50 > Type = 48 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 50 > Type = 48 > Type = 10 > Type = 10 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 50 > Type = 48 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 50 > Type = 48 > Type = 50 > Type = 48 > Type = 10 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 1 > Unhandled type = 1 > Type = 1 > Unhandled type = 1 > Type = 1 > Unhandled type = 1 > Type = 1 > Unhandled type = 1 > Type = 1 > Unhandled type = 1 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 1 > Unhandled type = 1 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 1 > Unhandled type = 1 > Type = 1 > Unhandled type = 1 > Type = 1 > Unhandled type = 1 > Type = 1 > Unhandled type = 1 > Type = 1 > Unhandled type = 1 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > > # more main.c > int main () > { > } > > # clang -fuse-ld=lld -g main.c > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 50 > Type = 48 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 10 > Type = 10 > Type = 50 > Type = 64 > Type = 50 > Type = 48 > Type = 10 > Type = 50 > Type = 50 > Type = 64 > Type = 64 > Type = 50 > Type = 64 > Type = 50 > Type = 50 > Type = 64 > Type = 64 > Type = 50 > Type = 50 > Type = 64 > Type = 64 > Type = 10 > Type = 50 > Type = 64 > Type = 50 > Type = 50 > Type = 64 > Type = 64 > Type = 10 > Type = 10 > Type = 50 > Type = 50 > Type = 64 > Type = 64 > Type = 50 > Type = 50 > Type = 64 > Type = 64 > Type = 10 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 50 > Type = 48 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 64 > Type = 50 > Type = 48 > Type = 50 > Type = 64 > Type = 50 > Type = 64 > Type = 50 > Type = 48 > Type = 10 > Type = 10 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 50 > Type = 48 > Type = 50 > Type = 48 > Type = 10 > Type = 38 > Unhandled type = 38 > Type = 51 > Type = 1 > Unhandled type = 1 > Type = 1 > Unhandled type = 1 > Type = 1 > Unhandled type = 1 > Type = 1 > Unhandled type = 1 > Type = 1 > Unhandled type = 1 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > Type = 1 > Unhandled type = 1 > Type = 1 > Unhandled type = 1 > Type = 1 > Unhandled type = 1 > Type = 1 > Unhandled type = 1 > Type = 1 > Unhandled type = 1 > Type = 38 > Unhandled type = 38 > Type = 38 > Unhandled type = 38 > > > === > Mark Millard > markmi at dsl-only.net > > On 2017-Jan-18, at 3:41 PM, Mark Millard wrote: > > On 2017-Jan-18, at 1:54 PM, Roman Divacky 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. > > From 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? > > 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 > > > > Index: ../tools/lld/ELF/Target.cpp > > =================================================================== > > --- ../tools/lld/ELF/Target.cpp (revision 292428) > > +++ ../tools/lld/ELF/Target.cpp (working copy) > > @@ -1075,7 +1075,8 @@ > > } > > > > PPC64TargetInfo::PPC64TargetInfo() { > > - PltRel = GotRel = R_PPC64_GLOB_DAT; > > + GotRel = R_PPC64_GLOB_DAT; > > + PltRel = R_PPC64_JMP_SLOT; > > RelativeRel = R_PPC64_RELATIVE; > > GotEntrySize = 8; > > GotPltEntrySize = 8; > > @@ -1114,8 +1115,10 @@ > > } > > > > RelExpr PPC64TargetInfo::getRelExpr(uint32_t Type, const SymbolBody &S) const { > > + llvm::outs() << "Type = " << Type << ", name = " << S.getName() << "\n"; > > switch (Type) { > > default: > > + llvm::outs() << "Unhandled type = " << 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. > > === > 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): > > > > uint64_t TocVA = Out::Plt->getVA(); > > > > changed the behavior and it gets farther for > > -fuse-ld=lld 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==0x10018560 initially in __do_global_ctors_aux > > seems wrong. If so then objlist_call_init produced > > a wrong r2 value. > > > > [I've no clue if this is what you expected from > > the Plt experiment or not.] > > > > Details. . . > > > > # /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 > > > > 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=, lockstate=) at /usr/src/libexec/rtld-elf/rtld.c:2541 > > #3 0x0000000050029fa8 in _rtld (sp=, exit_proc=, objp=) 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 <<<<<==== 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 > > => 0x00000000100104a8 <+56>: ld r4,8(r3) <<<<<==== 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 <<<<<==== 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 > > 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 > > > > > > === > > Mark Millard > > markmi at dsl-only.net > > > > On 2017-Jan-17, at 1:56 PM, Roman Divacky wrote: > > > >> Go with Out. > >> > >> On Tue, Jan 17, 2017 at 01:53:14PM -0800, Mark Millard wrote: > >>> 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). > >>>> > >>>> LLD understands that we use GOT as TOC (which was true before my patch), > >>>> I wonder if something like this: > >>>> > >>>> ndex: tools/lld/ELF/Target.cpp > >>>> =================================================================== > >>>> --- tools/lld/ELF/Target.cpp (revision 292071) > >>>> +++ tools/lld/ELF/Target.cpp (working copy) > >>>> @@ -1070,7 +1070,8 @@ > >>>> } > >>>> > >>>> PPC64TargetInfo::PPC64TargetInfo() { > >>>> - PltRel = GotRel = R_PPC64_GLOB_DAT; > >>>> + GotRel = R_PPC64_GLOB_DAT; > >>>> + PltRel = R_PPC64_JMP_SLOT; > >>>> RelativeRel = R_PPC64_RELATIVE; > >>>> GotEntrySize = 8; > >>>> GotPltEntrySize = 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 = In::Got->getVA(); > >>>> + uint64_t TocVA = In::Plt->getVA(); > >>>> > >>>> // 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 = Out::Got->getVA(); > >>> > >>> // 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 <<<<<===== NOTE!!!! > >>> 0x0000000010020000 - 0x0000000010020010 is .ctors > >>> 0x0000000010020010 - 0x0000000010020020 is .dtors > >>> 0x0000000010020020 - 0x0000000010020028 is .jcr > >>> 0x0000000010020028 - 0x0000000010020138 is .dynamic > >>> 0x0000000010020138 - 0x0000000010020138 is .got <<<<<===== NOTE!!!! > >>> 0x0000000010030000 - 0x0000000010030019 is .data > >>> 0x0000000010030020 - 0x0000000010030050 is .got.plt <<<<<===== NOTE!!!! > >>> 0x0000000010030050 - 0x00000000100300a0 is .toc <<<<<===== 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. > >>> > >>> === > >>> Mark Millard > >>> markmi at dsl-only.net > > _______________________________________________ > 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" > > _______________________________________________ > 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" > > _______________________________________________ > 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" From owner-freebsd-toolchain@freebsd.org Thu Jan 19 23:14: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 47A14CB86CE for ; Thu, 19 Jan 2017 23:14: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 ED8D21E16 for ; Thu, 19 Jan 2017 23:14:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12587 invoked from network); 19 Jan 2017 23:14:20 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 19 Jan 2017 23:14:20 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Thu, 19 Jan 2017 18:14:20 -0500 (EST) Received: (qmail 6879 invoked from network); 19 Jan 2017 23:14:19 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 19 Jan 2017 23:14:19 -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 E6D95EC7B46; Thu, 19 Jan 2017 15:14:18 -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: <20170119200530.GA58089@vlakno.cz> Date: Thu, 19 Jan 2017 15:14:18 -0800 Cc: FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <41DE5AA2-5794-4BE6-8BDD-C3C7C84F9C83@dsl-only.net> References: <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> <9023794B-0999-4F50-95DE-2D4156BC6E75@dsl-only.net> <545CE5A1-9E7F-46C0-8355-0C32B60D1C72@dsl-only.net> <278EB6CA-6A04-43D6-A9F2-84FF11A367C7@dsl-only.net> <20170119200530.GA58089@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: Thu, 19 Jan 2017 23:14:22 -0000 On 2017-Jan-19, at 12:05 PM, Roman Divacky = wrote: > Type =3D 38 should be R_ABS so thats fine. If what I expected to be in = .got > is in .got.plt, what happens if you modify the getPPC64TocBase() to > use ::GotPlt instead of ::Got ? For using GotPlt. . . -pie use still gets the notices: can't create dynamic relocation R_PPC64_REL24 against readonly segment The log messages do not change at all for GotPlt being in use: Plt, Got, and GotPlt all output the same messages during the compile/link based on ld.lld (other options being the same). (I diff'd the outputs.) # /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 Program received signal SIGSEGV, Segmentation fault. 0x00000000100104a0 in .__do_global_ctors_aux () (gdb) bt #0 0x00000000100104a0 in .__do_global_ctors_aux () #1 0x0000000010010508 in ._init () #2 0x000000005002ad1c in objlist_call_init (list=3D, = lockstate=3D) at /usr/src/libexec/rtld-elf/rtld.c:2546 #3 0x0000000050029fe4 in _rtld (sp=3D, = exit_proc=3D, objp=3D) at = /usr/src/libexec/rtld-elf/rtld.c:673 #4 0x00000000500279b0 in ._rtld_start () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:83 Backtrace stopped: frame did not save the PC In other words: the same as when Plt was used. And the code does not get near executing main. The difference in: /usr/local/powerpc64-freebsd/bin/objdump -d --prefix-addresses a.out output for Got vs. GotPlt is: (<: Got, >: GotPlt) < 0000000010010558 <.plt+0x8> ld r12,32512(r11) --- > 0000000010010558 <.plt+0x8> ld r12,-32744(r11) 346c346 < 0000000010010578 <.plt+0x28> ld r12,32520(r11) --- > 0000000010010578 <.plt+0x28> ld r12,-32736(r11) 354c354 < 0000000010010598 <.plt+0x48> ld r12,32528(r11) --- > 0000000010010598 <.plt+0x48> ld r12,-32728(r11) The GotPlt offset figures look better to me: near the beginning of the 64K range with zero offset being near the middle. (That does not of itself imply that r11 would be appropriate for the figures if the execution got this far.) Of course the .plt section is far before what you call the TOC, unlike in what the bfd linker does. (See below.) The following includes: 0x0000000010010550 - 0x00000000100105b0 is .plt . . . 0x0000000010030020 - 0x0000000010030050 is .got.plt 0x0000000010030050 - 0x00000000100300a0 is .toc . . . 0x000000005005ff00 - 0x000000005005ff08 is .got in = /libexec/ld-elf.so.1 . . . 0x000000005026f900 - 0x0000000050271f98 is .got in = /lib/libc.so.7 0x0000000050272000 - 0x0000000050277208 is .plt in = /lib/libc.so.7 (A mix of ld.lld and ld.bfd styles.) (gdb) info file Symbols from "/root/c_tests/a.out". Native process: Using the running image of child LWP 100168 of process 78109. 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 - 0x00000000100104f0 is .text 0x00000000100104f0 - 0x000000001001051c is .init 0x0000000010010520 - 0x0000000010010544 is .fini 0x0000000010010550 - 0x00000000100105b0 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 - 0x0000000050045ab4 is .text in = /libexec/ld-elf.so.1 0x0000000050045ab4 - 0x000000005004856b is .rodata in = /libexec/ld-elf.so.1 0x000000005004856c - 0x000000005004856c 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 =3D=3D=3D Mark Millard markmi at dsl-only.net On Thu, Jan 19, 2017 at 01:46:02AM -0800, Mark Millard wrote: > I should have noted that -pie gets the same sort of > readonly segment errors as -shared did: >=20 > # clang -fuse-ld=3Dlld -g -pie empty_src.c > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 10 > Type =3D 10 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 48 > Type =3D 10 > Type =3D 50 > Type =3D 50 > Type =3D 48 > Type =3D 48 > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 50 > Type =3D 48 > Type =3D 48 > Type =3D 50 > Type =3D 50 > Type =3D 48 > Type =3D 48 > Type =3D 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 50 > Type =3D 48 > Type =3D 48 > Type =3D 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type =3D 10 > Type =3D 50 > Type =3D 50 > Type =3D 48 > Type =3D 48 > Type =3D 50 > Type =3D 50 > Type =3D 48 > Type =3D 48 > Type =3D 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 10 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 64 > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 48 > Type =3D 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type =3D 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 48 > Type =3D 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > undefined symbol: main in /usr/lib/Scrt1.o > clang: error: linker command failed with exit code 1 (use -v to see = invocation) >=20 > # more main.c > int main () > { > } > # clang -fuse-ld=3Dlld -g -pie main.c > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 10 > Type =3D 10 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 48 > Type =3D 10 > Type =3D 50 > Type =3D 50 > Type =3D 48 > Type =3D 48 > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 50 > Type =3D 48 > Type =3D 48 > Type =3D 50 > Type =3D 50 > Type =3D 48 > Type =3D 48 > Type =3D 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 50 > Type =3D 48 > Type =3D 48 > Type =3D 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type =3D 10 > Type =3D 50 > Type =3D 50 > Type =3D 48 > Type =3D 48 > Type =3D 50 > Type =3D 50 > Type =3D 48 > Type =3D 48 > Type =3D 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 10 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 64 > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 48 > Type =3D 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type =3D 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 48 > Type =3D 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > clang: error: linker command failed with exit code 1 (use -v to see = invocation) >=20 >=20 > So making something with a relocatable global variable is = problematical > via lld. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2017-Jan-18, at 10:48 PM, Mark Millard = wrote: >=20 > The log messages code does not work because of Assertion failures: >=20 > # clang -fuse-ld=3Dlld -g main.c > Type =3D 50, name =3D Assertion failed: (!isLocal()), function = getName, file /usr/src/contrib/llvm/tools/lld/ELF/Symbols.cpp, line 100. > clang: error: unable to execute command: Abort trap (core dumped) > clang: error: linker command failed due to signal (use -v to see = invocation) >=20 > So for now I've disabled the name part of the line. At least we will > see the numeric type of each and the reports of any "unhandled" = values. >=20 > I decided to use the Got variation instead of the Plt variant first. >=20 > Some examples: >=20 > # more empty_src.c >=20 > # clang -fuse-ld=3Dlld -g -shared -o empty_src.so empty_src.c > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 10 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 64 > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 48 > Type =3D 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type =3D 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 48 > Type =3D 10 > can't create dynamic relocation R_PPC64_REL24 against readonly segment > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > clang: error: linker command failed with exit code 1 (use -v to see = invocation) >=20 > # clang -fuse-ld=3Dlld -g empty_src.c > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 10 > Type =3D 10 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 48 > Type =3D 10 > Type =3D 50 > Type =3D 50 > Type =3D 64 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 50 > Type =3D 64 > Type =3D 64 > Type =3D 50 > Type =3D 50 > Type =3D 64 > Type =3D 64 > Type =3D 10 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 50 > Type =3D 64 > Type =3D 64 > Type =3D 10 > Type =3D 10 > Type =3D 50 > Type =3D 50 > Type =3D 64 > Type =3D 64 > Type =3D 50 > Type =3D 50 > Type =3D 64 > Type =3D 64 > Type =3D 10 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 64 > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 48 > Type =3D 10 > Type =3D 10 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 48 > Type =3D 10 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > undefined symbol: main in /usr/lib/crt1.o > clang: error: linker command failed with exit code 1 (use -v to see = invocation) >=20 > # more main.c > volatile void* gblvar =3D 0; >=20 > int main () > { > gblvar =3D &gblvar; > } >=20 > # clang -fuse-ld=3Dlld -g main.c > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 10 > Type =3D 10 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 48 > Type =3D 10 > Type =3D 50 > Type =3D 50 > Type =3D 64 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 50 > Type =3D 64 > Type =3D 64 > Type =3D 50 > Type =3D 50 > Type =3D 64 > Type =3D 64 > Type =3D 10 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 50 > Type =3D 64 > Type =3D 64 > Type =3D 10 > Type =3D 10 > Type =3D 50 > Type =3D 50 > Type =3D 64 > Type =3D 64 > Type =3D 50 > Type =3D 50 > Type =3D 64 > Type =3D 64 > Type =3D 10 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 64 > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 48 > Type =3D 10 > Type =3D 10 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 50 > Type =3D 48 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 48 > Type =3D 10 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 1 > Unhandled type =3D 1 > Type =3D 1 > Unhandled type =3D 1 > Type =3D 1 > Unhandled type =3D 1 > Type =3D 1 > Unhandled type =3D 1 > Type =3D 1 > Unhandled type =3D 1 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 1 > Unhandled type =3D 1 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 1 > Unhandled type =3D 1 > Type =3D 1 > Unhandled type =3D 1 > Type =3D 1 > Unhandled type =3D 1 > Type =3D 1 > Unhandled type =3D 1 > Type =3D 1 > Unhandled type =3D 1 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 >=20 > # more main.c > int main () > { > } >=20 > # clang -fuse-ld=3Dlld -g main.c > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 10 > Type =3D 10 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 48 > Type =3D 10 > Type =3D 50 > Type =3D 50 > Type =3D 64 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 50 > Type =3D 64 > Type =3D 64 > Type =3D 50 > Type =3D 50 > Type =3D 64 > Type =3D 64 > Type =3D 10 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 50 > Type =3D 64 > Type =3D 64 > Type =3D 10 > Type =3D 10 > Type =3D 50 > Type =3D 50 > Type =3D 64 > Type =3D 64 > Type =3D 50 > Type =3D 50 > Type =3D 64 > Type =3D 64 > Type =3D 10 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 64 > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 64 > Type =3D 50 > Type =3D 48 > Type =3D 10 > Type =3D 10 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 50 > Type =3D 48 > Type =3D 50 > Type =3D 48 > Type =3D 10 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 51 > Type =3D 1 > Unhandled type =3D 1 > Type =3D 1 > Unhandled type =3D 1 > Type =3D 1 > Unhandled type =3D 1 > Type =3D 1 > Unhandled type =3D 1 > Type =3D 1 > Unhandled type =3D 1 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 1 > Unhandled type =3D 1 > Type =3D 1 > Unhandled type =3D 1 > Type =3D 1 > Unhandled type =3D 1 > Type =3D 1 > Unhandled type =3D 1 > Type =3D 1 > Unhandled type =3D 1 > Type =3D 38 > Unhandled type =3D 38 > Type =3D 38 > Unhandled type =3D 38 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2017-Jan-18, at 3:41 PM, Mark Millard wrote: >=20 > On 2017-Jan-18, at 1:54 PM, Roman Divacky wrote: >=20 >> 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. >=20 > =46rom what I've read: for code references the .got.plt section would > be involved when it exists, not the .got section. >=20 >> For some reason, GOT is empty, in our case. >=20 > I think that I've already explained this: lld produces two different > sections instead of just one .got section: .got and .got.plt . >=20 > .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. >=20 > .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. >=20 > 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. >=20 >> I believe this might be caused >> by a relocation thats wrongly mapped to R_ABS in = PPC64TargetInfo::getRelExpr(). >=20 > 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. >=20 > 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. >=20 > 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). >=20 >> 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 >=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. >=20 > Then I'll retry with the Plt use reverted. >=20 >> 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: >=20 > 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. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > 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::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, = lockstate=3D) at /usr/src/libexec/rtld-elf/rtld.c:2541 >> #3 0x0000000050029fa8 in _rtld (sp=3D, = exit_proc=3D, objp=3D) 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 >> 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 = 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 = 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::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 >>>>=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::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 >=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" >=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" >=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" From owner-freebsd-toolchain@freebsd.org Fri Jan 20 08:54:13 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 DBDCBCB8984 for ; Fri, 20 Jan 2017 08:54:13 +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 8CE4A1050 for ; Fri, 20 Jan 2017 08:54:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 16354 invoked from network); 20 Jan 2017 08:54:06 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 20 Jan 2017 08:54:06 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Fri, 20 Jan 2017 03:54:06 -0500 (EST) Received: (qmail 24488 invoked from network); 20 Jan 2017 08:54:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Jan 2017 08:54:06 -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 E3A31EC7D56; Fri, 20 Jan 2017 00:54:04 -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: <41DE5AA2-5794-4BE6-8BDD-C3C7C84F9C83@dsl-only.net> Date: Fri, 20 Jan 2017 00:54:01 -0800 Cc: Ed Maste , FreeBSD Toolchain , Justin Hibbits , Nathan Whitehorn Content-Transfer-Encoding: quoted-printable Message-Id: <401EB857-2C19-4CC3-A9F1-8353759B51F5@dsl-only.net> References: <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> <9023794B-0999-4F50-95DE-2D4156BC6E75@dsl-only.net> <545CE5A1-9E7F-46C0-8355-0C32B60D1C72@dsl-only.net> <278EB6CA-6A04-43D6-A9F2-84FF11A367C7@dsl-only.net> <20170119200530.GA58089@vlakno.cz> <41DE5AA2-5794-4BE6-8BDD-C3C7C84F9C83@dsl-only.net> 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: Fri, 20 Jan 2017 08:54:14 -0000 I did a bunch more investigation and have 4 major points that I think I've established: First off: I've still not found a single example of a document's coverage of powerpc64 (or powerpc) that deals with the .got vs. .got.plt split [.got in RELRO region but .got.plt possibly not (lazy relocation then allowed)]. Everything that I have found is specific to Intel architecture for that split. There may be no defined powerpc64 ABI that uses .got.plt. If so then ld.lld's use of .got.plt for powerpc64 may be an ABI violation (for all powerpc64 ABIs). Secondly: The (nonppc) references that I've found indicate that RELRO+-PIE+-fPIE sorts of contexts for .got.plt usage. .got.plt may be in the RELRO region if lazy relocation is t be disallowed but .got.plt is not in the RELRO region when lazy relocation is allowed. I've not found references to .got.plt for when there is no RELRO. Nor when there is no PIE. Thirdly: a.out from ld.lld is not using function descriptors or its 3 fields. The .plt is blocks of code and the relocated addresses are in the .got.plt --without room for the function descriptors. /usr/src/libexec/rtld-elf/powerpc64/reloc.c has no code for the ld.lld .plt / .got.plt pairing that ld.lld outputs in a.out, not in the likes of its reloc_jmpslots, reloc_jmpslot, or reloc_plt. reloc.c is trashing memory by putting function descriptor content in place when it should not from what I can tell. Fourthly: Got is correct and the GotPlt and Plt alternatives are wrong for in uint64_t getPPC64TocBase() . (Sorry I sent you in the wrong direction for this area.) The rest of this note is related the "fourthly" and "thirdly" above but is only relevant if more detail is wanted. I deal with "fourthly" first. . . I was wrong about Got vs. Plt vs. GotPlt in: uint64_t getPPC64TocBase() as for as what the code should reference: I've solid evidence that Got is correct. One part of that is what I'll present here as it should be sufficient: Got stops during /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 = called code Plt stops during /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:83 = called code GotPlt stops during /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:83 = called code The Got case executed the rtld_start.S:83 related code correctly and later fails. (I've traced relevant code under gdb.) So the below is based on analyzing the Got variant. Now for "thirdly" (lack of function descriptors in .plt). . . A ld.bfd vs. ld.lld difference is the r_offset differences are smaller in ld.bfd and larger in ld.lld and the relocations are in different sections: a.out from ld.lld is not using function descriptors or its 3 fields. . . For ld.bfd's generated a.out: 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 is an increment of 0x18 between entries (room for the function descriptors). The r_offset's are from the ld.bfd generated .plt section: 0x0000000010021898 - 0x00000000100218f8 is .plt (gdb) x/12gx 0x0000000010021898 0x10021898: 0x00000000500189f0 0x0000000050058f00 0x100218a8: 0x000000005003d000 0x000000005021a7e0 0x100218b8: 0x0000000050299900 0x0000000000000000 0x100218c8: 0x0000000010000988 0x0000000000000000 0x100218d8: 0x0000000000000000 0x0000000010000990 0x100218e8: 0x0000000000000000 0x0000000000000000 (gdb) info symbol 0x000000005021a7e0 .atexit in section .text of /lib/libc.so.7 (gdb) info symbol 0x0000000010000988 _init_tls@plt in section .text of /root/c_tests/a.out (gdb) info symbol 0x0000000010000990 exit@plt in section .text of /root/c_tests/a.out NOTE: The .plt contains no code, just function descriptors. By comparison for what ld.lld generated: 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 These r_offset's are in the .got.plt area, not in the .plt area: 0x0000000010030020 - 0x0000000010030050 is .got.plt The increment is 0x8 between entries, not 0x18. There are no function descriptor here. The actual content from the /usr/src/libexec/rtld-elf/powerpc64/reloc.c code results ends up being as shown: (gdb) x/6gx 0x10030038 0x10030038: 0x0000000000000020 0x0000000000000028 0x10030048: 0x0000000000000030 0x0000000010030168 0x10030058: 0x0000000010030160 0x0000000010020028 which appears to be incorrect for how the 0(r12) code is used buy the .plt code (shown below) and leads to the crash. For another the .plt code below expects to compute r12 and then use 0(1r12), 8(r12), and 16(r12) for the function descriptor entries --but there is no room for such. For ld.lld's a.out its .plt (not .got.plt) is code, unlike in the ld.bfd generated a.out: 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) Note: r11=3D=3D0x20 = results 0000000010010560 <.plt+0x10> mtctr r11 Note: ctr=3D=3D0x20 = results 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 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. 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) Note: r11=3D=3D0x28 = results 0000000010010580 <.plt+0x30> mtctr r11 Note: ctr=3D=3D0x28 = results 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 Note: 0x000010030050 is from: 0x0000000010030050 - 0x00000000100300a0 is .toc 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) Note: r11=3D=3D0x30 = results 00000000100105a0 <.plt+0x50> mtctr r11 Note: ctr=3D=3D0x30 = results 00000000100105a4 <.plt+0x54> ld r2,8(r12) Note: accesses = 0x000010030050 00000000100105a8 <.plt+0x58> ld r11,16(r12) Note: accesses = 0x000010030058 00000000100105ac <.plt+0x5c> bctr Note: 0x000010030050 and 0x000010030058 are from: 0x0000000010030050 - 0x00000000100300a0 is .toc This code seems to expect function descriptors [8(r12) and 16(r12) = accesses] but no such function descriptors or space for them is set up. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-19, at 3:14 PM, Mark Millard wrote: > On 2017-Jan-19, at 12:05 PM, Roman Divacky = wrote: >=20 >> Type =3D 38 should be R_ABS so thats fine. If what I expected to be = in .got >> is in .got.plt, what happens if you modify the getPPC64TocBase() to >> use ::GotPlt instead of ::Got ? >=20 > For using GotPlt. . . >=20 > -pie use still gets the notices: >=20 > can't create dynamic relocation R_PPC64_REL24 against readonly segment >=20 > The log messages do not change at all for GotPlt being in use: Plt, = Got, > and GotPlt all output the same messages during the compile/link based > on ld.lld (other options being the same). (I diff'd the outputs.) >=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. > 0x00000000100104a0 in .__do_global_ctors_aux () > (gdb) bt > #0 0x00000000100104a0 in .__do_global_ctors_aux () > #1 0x0000000010010508 in ._init () > #2 0x000000005002ad1c in objlist_call_init (list=3D, = lockstate=3D) at /usr/src/libexec/rtld-elf/rtld.c:2546 > #3 0x0000000050029fe4 in _rtld (sp=3D, = exit_proc=3D, objp=3D) at = /usr/src/libexec/rtld-elf/rtld.c:673 > #4 0x00000000500279b0 in ._rtld_start () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:83 > Backtrace stopped: frame did not save the PC >=20 > In other words: the same as when Plt was used. >=20 > And the code does not get near executing main. >=20 > The difference in: >=20 > /usr/local/powerpc64-freebsd/bin/objdump -d --prefix-addresses a.out >=20 > output for Got vs. GotPlt is: > (<: Got, >: GotPlt) >=20 > < 0000000010010558 <.plt+0x8> ld r12,32512(r11) > --- >> 0000000010010558 <.plt+0x8> ld r12,-32744(r11) > 346c346 > < 0000000010010578 <.plt+0x28> ld r12,32520(r11) > --- >> 0000000010010578 <.plt+0x28> ld r12,-32736(r11) > 354c354 > < 0000000010010598 <.plt+0x48> ld r12,32528(r11) > --- >> 0000000010010598 <.plt+0x48> ld r12,-32728(r11) >=20 > The GotPlt offset figures look better to me: near the beginning > of the 64K range with zero offset being near the middle. (That > does not of itself imply that r11 would be appropriate for the > figures if the execution got this far.) >=20 > Of course the .plt section is far before what you call > the TOC, unlike in what the bfd linker does. (See below.) >=20 > The following includes: >=20 > 0x0000000010010550 - 0x00000000100105b0 is .plt > . . . > 0x0000000010030020 - 0x0000000010030050 is .got.plt > 0x0000000010030050 - 0x00000000100300a0 is .toc > . . . > 0x000000005005ff00 - 0x000000005005ff08 is .got in = /libexec/ld-elf.so.1 > . . . > 0x000000005026f900 - 0x0000000050271f98 is .got in = /lib/libc.so.7 > 0x0000000050272000 - 0x0000000050277208 is .plt in = /lib/libc.so.7 >=20 > (A mix of ld.lld and ld.bfd styles.) >=20 > (gdb) info file > Symbols from "/root/c_tests/a.out". > Native process: > Using the running image of child LWP 100168 of process 78109. > 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 - 0x00000000100104f0 is .text > 0x00000000100104f0 - 0x000000001001051c is .init > 0x0000000010010520 - 0x0000000010010544 is .fini > 0x0000000010010550 - 0x00000000100105b0 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 - 0x0000000050045ab4 is .text in = /libexec/ld-elf.so.1 > 0x0000000050045ab4 - 0x000000005004856b is .rodata in = /libexec/ld-elf.so.1 > 0x000000005004856c - 0x000000005004856c 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 From owner-freebsd-toolchain@freebsd.org Fri Jan 20 17:37:36 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 4F3ADCB8459 for ; Fri, 20 Jan 2017 17:37:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 3E7EC11E9 for ; Fri, 20 Jan 2017 17:37:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0KHbZrs093726 for ; Fri, 20 Jan 2017 17:37:36 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216316] objcopy in 11 appears to have a regression compared to the version in 10 Date: Fri, 20 Jan 2017 17:37:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: cem@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Fri, 20 Jan 2017 17:37:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216316 Conrad Meyer changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cem@freebsd.org, | |emaste@freebsd.org Assignee|freebsd-bugs@FreeBSD.org |freebsd-toolchain@FreeBSD.o | |rg --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Jan 20 17:43:48 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 88D75CB88C8 for ; Fri, 20 Jan 2017 17:43:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 73BA61C00 for ; Fri, 20 Jan 2017 17:43:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0KHhmks011179 for ; Fri, 20 Jan 2017 17:43:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216316] objcopy in 11 appears to have a regression compared to the version in 10 Date: Fri, 20 Jan 2017 17:43:48 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: emaste@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Fri, 20 Jan 2017 17:43:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216316 --- Comment #1 from Ed Maste --- objcopy in 11 and later comes from ELF Tool Chain instead of GNU binutils. Would you attach bin/ipxe.pxe.tmp to this PR for further investigation? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Jan 20 23:20:00 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 1AA18CBA773 for ; Fri, 20 Jan 2017 23:20:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-14.reflexion.net [208.70.210.14]) (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 CCFB0107E for ; Fri, 20 Jan 2017 23:19:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3831 invoked from network); 20 Jan 2017 23:19:52 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 20 Jan 2017 23:19:52 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Fri, 20 Jan 2017 18:19:52 -0500 (EST) Received: (qmail 22977 invoked from network); 20 Jan 2017 23:19:51 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Jan 2017 23:19:51 -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 14254EC823F; Fri, 20 Jan 2017 15:19:51 -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: <401EB857-2C19-4CC3-A9F1-8353759B51F5@dsl-only.net> Date: Fri, 20 Jan 2017 15:19:47 -0800 Cc: FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <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> <9023794B-0999-4F50-95DE-2D4156BC6E75@dsl-only.net> <545CE5A1-9E7F-46C0-8355-0C32B60D1C72@dsl-only.net> <278EB6CA-6A04-43D6-A9F2-84FF11A367C7@dsl-only.net> <20170119200530.GA58089@vlakno.cz> <41DE5AA2-5794-4BE6-8BDD-C3C7C84F9C83@dsl-only.net> <401EB857-2C19-4CC3-A9F1-8353759B51F5@dsl-only.net> 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: Fri, 20 Jan 2017 23:20:00 -0000 FYI: 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: void PPC64TargetInfo::writePlt(uint8_t *Buf, uint64_t GotEntryAddr, uint64_t PltEntryAddr, int32_t Index, unsigned RelOff) const { uint64_t Off =3D GotEntryAddr - getPPC64TocBase(); // 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 } Either the .got.plt entry layout changes to have room for 8(r12) and 16(r12) positions (size change to 0x18 Bytes per entryr) 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.) Unlike what the comment says this code does not reference the .opd section at all as things are right now. See the prior Email content below for the details as in the example used. It references the .got.plt and the .toc section via r12 in the example (the size mismatch from the layout mismatch). =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-20, at 12:54 AM, Mark Millard = wrote: > I did a bunch more investigation and have 4 major points > that I think I've established: >=20 > First off: I've still not found a single example > of a document's coverage of powerpc64 (or powerpc) that > deals with the .got vs. .got.plt split [.got in RELRO region > but .got.plt possibly not (lazy relocation then allowed)]. > Everything that I have found is specific to Intel architecture > for that split. There may be no defined powerpc64 ABI that uses > .got.plt. If so then ld.lld's use of .got.plt for powerpc64 may > be an ABI violation (for all powerpc64 ABIs). >=20 > Secondly: The (nonppc) references that I've found indicate > that RELRO+-PIE+-fPIE sorts of contexts for .got.plt usage. > .got.plt may be in the RELRO region if lazy relocation > is t be disallowed but .got.plt is not in the RELRO > region when lazy relocation is allowed. I've not > found references to .got.plt for when there is no RELRO. > Nor when there is no PIE. >=20 > Thirdly: a.out from ld.lld is not using function > descriptors or its 3 fields. The .plt is blocks > of code and the relocated addresses are in the > .got.plt --without room for the function > descriptors. /usr/src/libexec/rtld-elf/powerpc64/reloc.c > has no code for the ld.lld .plt / .got.plt pairing > that ld.lld outputs in a.out, not in the likes of its > reloc_jmpslots, reloc_jmpslot, or reloc_plt. reloc.c > is trashing memory by putting function descriptor > content in place when it should not from what I can > tell. >=20 > Fourthly: Got is correct and the GotPlt and Plt > alternatives are wrong for in uint64_t getPPC64TocBase() . > (Sorry I sent you in the wrong direction for this area.) >=20 > The rest of this note is related the "fourthly" and > "thirdly" above but is only relevant if more detail > is wanted. >=20 >=20 > I deal with "fourthly" first. . . >=20 > I was wrong about Got vs. Plt vs. GotPlt in: >=20 > uint64_t getPPC64TocBase() >=20 > as for as what the code should reference: I've solid > evidence that Got is correct. One part of that is > what I'll present here as it should be sufficient: >=20 > Got stops during /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 = called code > Plt stops during /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:83 = called code > GotPlt stops during = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:83 called code >=20 > The Got case executed the rtld_start.S:83 related code correctly > and later fails. (I've traced relevant code under gdb.) >=20 > So the below is based on analyzing the Got variant. >=20 >=20 > Now for "thirdly" (lack of function descriptors in .plt). . . >=20 > A ld.bfd vs. ld.lld difference is the r_offset differences > are smaller in ld.bfd and larger in ld.lld and the relocations are > in different sections: a.out from ld.lld is not using function > descriptors or its 3 fields. . . >=20 > For ld.bfd's generated a.out: >=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 > (gdb) x/12gx 0x0000000010021898 > 0x10021898: 0x00000000500189f0 0x0000000050058f00 > 0x100218a8: 0x000000005003d000 0x000000005021a7e0 > 0x100218b8: 0x0000000050299900 0x0000000000000000 > 0x100218c8: 0x0000000010000988 0x0000000000000000 > 0x100218d8: 0x0000000000000000 0x0000000010000990 > 0x100218e8: 0x0000000000000000 0x0000000000000000 > (gdb) info symbol 0x000000005021a7e0 > .atexit in section .text of /lib/libc.so.7 > (gdb) info symbol 0x0000000010000988 > _init_tls@plt in section .text of /root/c_tests/a.out > (gdb) info symbol 0x0000000010000990 > exit@plt in section .text of /root/c_tests/a.out >=20 > NOTE: The .plt contains no code, just function descriptors. >=20 > By comparison for what ld.lld generated: >=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. There are no > function descriptor here. >=20 > The actual content from the = /usr/src/libexec/rtld-elf/powerpc64/reloc.c > code results ends up being as shown: >=20 > (gdb) x/6gx 0x10030038 > 0x10030038: 0x0000000000000020 0x0000000000000028 > 0x10030048: 0x0000000000000030 0x0000000010030168 > 0x10030058: 0x0000000010030160 0x0000000010020028 >=20 > which appears to be incorrect for how the 0(r12) code is used > buy the .plt code (shown below) and leads to the crash. For > another the .plt code below expects to compute r12 and then > use 0(1r12), 8(r12), and 16(r12) for the function descriptor > entries --but there is no room for such. >=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) Note: r11=3D=3D0x20 = results > 0000000010010560 <.plt+0x10> mtctr r11 Note: ctr=3D=3D0x20 = results > 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) Note: r11=3D=3D0x28 = results > 0000000010010580 <.plt+0x30> mtctr r11 Note: ctr=3D=3D0x28 = results > 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) Note: r11=3D=3D0x30 = results > 00000000100105a0 <.plt+0x50> mtctr r11 Note: ctr=3D=3D0x30 = results > 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 > This code seems to expect function descriptors [8(r12) and 16(r12) = accesses] > but no such function descriptors or space for them is set up. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2017-Jan-19, at 3:14 PM, Mark Millard = wrote: >=20 >> On 2017-Jan-19, at 12:05 PM, Roman Divacky = wrote: >>=20 >>> Type =3D 38 should be R_ABS so thats fine. If what I expected to be = in .got >>> is in .got.plt, what happens if you modify the getPPC64TocBase() to >>> use ::GotPlt instead of ::Got ? >>=20 >> For using GotPlt. . . >>=20 >> -pie use still gets the notices: >>=20 >> can't create dynamic relocation R_PPC64_REL24 against readonly = segment >>=20 >> The log messages do not change at all for GotPlt being in use: Plt, = Got, >> and GotPlt all output the same messages during the compile/link based >> on ld.lld (other options being the same). (I diff'd the outputs.) >>=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. >> 0x00000000100104a0 in .__do_global_ctors_aux () >> (gdb) bt >> #0 0x00000000100104a0 in .__do_global_ctors_aux () >> #1 0x0000000010010508 in ._init () >> #2 0x000000005002ad1c in objlist_call_init (list=3D, = lockstate=3D) at /usr/src/libexec/rtld-elf/rtld.c:2546 >> #3 0x0000000050029fe4 in _rtld (sp=3D, = exit_proc=3D, objp=3D) at = /usr/src/libexec/rtld-elf/rtld.c:673 >> #4 0x00000000500279b0 in ._rtld_start () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:83 >> Backtrace stopped: frame did not save the PC >>=20 >> In other words: the same as when Plt was used. >>=20 >> And the code does not get near executing main. >>=20 >> The difference in: >>=20 >> /usr/local/powerpc64-freebsd/bin/objdump -d --prefix-addresses a.out >>=20 >> output for Got vs. GotPlt is: >> (<: Got, >: GotPlt) >>=20 >> < 0000000010010558 <.plt+0x8> ld r12,32512(r11) >> --- >>> 0000000010010558 <.plt+0x8> ld r12,-32744(r11) >> 346c346 >> < 0000000010010578 <.plt+0x28> ld r12,32520(r11) >> --- >>> 0000000010010578 <.plt+0x28> ld r12,-32736(r11) >> 354c354 >> < 0000000010010598 <.plt+0x48> ld r12,32528(r11) >> --- >>> 0000000010010598 <.plt+0x48> ld r12,-32728(r11) >>=20 >> The GotPlt offset figures look better to me: near the beginning >> of the 64K range with zero offset being near the middle. (That >> does not of itself imply that r11 would be appropriate for the >> figures if the execution got this far.) >>=20 >> Of course the .plt section is far before what you call >> the TOC, unlike in what the bfd linker does. (See below.) >>=20 >> The following includes: >>=20 >> 0x0000000010010550 - 0x00000000100105b0 is .plt >> . . . >> 0x0000000010030020 - 0x0000000010030050 is .got.plt >> 0x0000000010030050 - 0x00000000100300a0 is .toc >> . . . >> 0x000000005005ff00 - 0x000000005005ff08 is .got in = /libexec/ld-elf.so.1 >> . . . >> 0x000000005026f900 - 0x0000000050271f98 is .got in = /lib/libc.so.7 >> 0x0000000050272000 - 0x0000000050277208 is .plt in = /lib/libc.so.7 >>=20 >> (A mix of ld.lld and ld.bfd styles.) >>=20 >> (gdb) info file >> Symbols from "/root/c_tests/a.out". >> Native process: >> Using the running image of child LWP 100168 of process 78109. >> 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 - 0x00000000100104f0 is .text >> 0x00000000100104f0 - 0x000000001001051c is .init >> 0x0000000010010520 - 0x0000000010010544 is .fini >> 0x0000000010010550 - 0x00000000100105b0 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 - 0x0000000050045ab4 is .text in = /libexec/ld-elf.so.1 >> 0x0000000050045ab4 - 0x000000005004856b is .rodata in = /libexec/ld-elf.so.1 >> 0x000000005004856c - 0x000000005004856c 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 From owner-freebsd-toolchain@freebsd.org Sat Jan 21 01:05:09 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 DF0F8CB8129 for ; Sat, 21 Jan 2017 01:05:09 +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 982B21B1D for ; Sat, 21 Jan 2017 01:05:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13570 invoked from network); 21 Jan 2017 01:05:01 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 21 Jan 2017 01:05:01 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Fri, 20 Jan 2017 20:05:01 -0500 (EST) Received: (qmail 5857 invoked from network); 21 Jan 2017 01:05:01 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 21 Jan 2017 01:05:01 -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 5BD6EEC863D; Fri, 20 Jan 2017 17:05:00 -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: Date: Fri, 20 Jan 2017 17:04:59 -0800 Cc: FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <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> <9023794B-0999-4F50-95DE-2D4156BC6E75@dsl-only.net> <545CE5A1-9E7F-46C0-8355-0C32B60D1C72@dsl-only.net> <278EB6CA-6A04-43D6-A9F2-84FF11A367C7@dsl-only.net> <20170119200530.GA58089@vlakno.cz> <41DE5AA2-5794-4BE6-8BDD-C3C7C84F9C83@dsl-only.net> <401EB857-2C19-4CC3-A9F1-8353759B51F5@dsl-only.net> 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: Sat, 21 Jan 2017 01:05:10 -0000 On 2017-Jan-20, at 3:19 PM, Mark Millard wrote: > FYI: 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 > Either the .got.plt entry layout changes to have room > for 8(r12) and 16(r12) positions (size change to 0x18 > Bytes per entryr) 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.) >=20 > Unlike what the comment says this code does not reference > the .opd section at all as things are right now. See the > prior Email content below for the details as in the > example used. It references the .got.plt and the .toc > section via r12 in the example (the size mismatch > from the layout mismatch). It looks like the other side of this that is not establishing space for function descriptors is in the code in: /usr/src/contrib/llvm/tools/lld/ELF/Relocations.cpp in its scanRelocs : // At this point we are done with the relocated position. Some = relocations // also require us to create a got or plt entry. // 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; } The code is explicitly targeting creating GotPlt space, not .opd space, as well. The effect of such code and the wrtPlt code need to be correctly matching but currently are not. [I'm likely telling you want you already know. But for me these are finds that took a fair amount of time to discover: very unfamiliar source code.] =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-20, at 12:54 AM, Mark Millard = wrote: > I did a bunch more investigation and have 4 major points > that I think I've established: >=20 > First off: I've still not found a single example > of a document's coverage of powerpc64 (or powerpc) that > deals with the .got vs. .got.plt split [.got in RELRO region > but .got.plt possibly not (lazy relocation then allowed)]. > Everything that I have found is specific to Intel architecture > for that split. There may be no defined powerpc64 ABI that uses > .got.plt. If so then ld.lld's use of .got.plt for powerpc64 may > be an ABI violation (for all powerpc64 ABIs). >=20 > Secondly: The (nonppc) references that I've found indicate > that RELRO+-PIE+-fPIE sorts of contexts for .got.plt usage. > .got.plt may be in the RELRO region if lazy relocation > is t be disallowed but .got.plt is not in the RELRO > region when lazy relocation is allowed. I've not > found references to .got.plt for when there is no RELRO. > Nor when there is no PIE. >=20 > Thirdly: a.out from ld.lld is not using function > descriptors or its 3 fields. The .plt is blocks > of code and the relocated addresses are in the > .got.plt --without room for the function > descriptors. /usr/src/libexec/rtld-elf/powerpc64/reloc.c > has no code for the ld.lld .plt / .got.plt pairing > that ld.lld outputs in a.out, not in the likes of its > reloc_jmpslots, reloc_jmpslot, or reloc_plt. reloc.c > is trashing memory by putting function descriptor > content in place when it should not from what I can > tell. >=20 > Fourthly: Got is correct and the GotPlt and Plt > alternatives are wrong for in uint64_t getPPC64TocBase() . > (Sorry I sent you in the wrong direction for this area.) >=20 > The rest of this note is related the "fourthly" and > "thirdly" above but is only relevant if more detail > is wanted. >=20 >=20 > I deal with "fourthly" first. . . >=20 > I was wrong about Got vs. Plt vs. GotPlt in: >=20 > uint64_t getPPC64TocBase() >=20 > as for as what the code should reference: I've solid > evidence that Got is correct. One part of that is > what I'll present here as it should be sufficient: >=20 > Got stops during /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 = called code > Plt stops during /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:83 = called code > GotPlt stops during = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:83 called code >=20 > The Got case executed the rtld_start.S:83 related code correctly > and later fails. (I've traced relevant code under gdb.) >=20 > So the below is based on analyzing the Got variant. >=20 >=20 > Now for "thirdly" (lack of function descriptors in .plt). . . >=20 > A ld.bfd vs. ld.lld difference is the r_offset differences > are smaller in ld.bfd and larger in ld.lld and the relocations are > in different sections: a.out from ld.lld is not using function > descriptors or its 3 fields. . . >=20 > For ld.bfd's generated a.out: >=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 > (gdb) x/12gx 0x0000000010021898 > 0x10021898: 0x00000000500189f0 0x0000000050058f00 > 0x100218a8: 0x000000005003d000 0x000000005021a7e0 > 0x100218b8: 0x0000000050299900 0x0000000000000000 > 0x100218c8: 0x0000000010000988 0x0000000000000000 > 0x100218d8: 0x0000000000000000 0x0000000010000990 > 0x100218e8: 0x0000000000000000 0x0000000000000000 > (gdb) info symbol 0x000000005021a7e0 > .atexit in section .text of /lib/libc.so.7 > (gdb) info symbol 0x0000000010000988 > _init_tls@plt in section .text of /root/c_tests/a.out > (gdb) info symbol 0x0000000010000990 > exit@plt in section .text of /root/c_tests/a.out >=20 > NOTE: The .plt contains no code, just function descriptors. >=20 > By comparison for what ld.lld generated: >=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. There are no > function descriptor here. >=20 > The actual content from the = /usr/src/libexec/rtld-elf/powerpc64/reloc.c > code results ends up being as shown: >=20 > (gdb) x/6gx 0x10030038 > 0x10030038: 0x0000000000000020 0x0000000000000028 > 0x10030048: 0x0000000000000030 0x0000000010030168 > 0x10030058: 0x0000000010030160 0x0000000010020028 >=20 > which appears to be incorrect for how the 0(r12) code is used > buy the .plt code (shown below) and leads to the crash. For > another the .plt code below expects to compute r12 and then > use 0(1r12), 8(r12), and 16(r12) for the function descriptor > entries --but there is no room for such. >=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) Note: r11=3D=3D0x20 = results > 0000000010010560 <.plt+0x10> mtctr r11 Note: ctr=3D=3D0x20 = results > 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) Note: r11=3D=3D0x28 = results > 0000000010010580 <.plt+0x30> mtctr r11 Note: ctr=3D=3D0x28 = results > 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) Note: r11=3D=3D0x30 = results > 00000000100105a0 <.plt+0x50> mtctr r11 Note: ctr=3D=3D0x30 = results > 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 > This code seems to expect function descriptors [8(r12) and 16(r12) = accesses] > but no such function descriptors or space for them is set up. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2017-Jan-19, at 3:14 PM, Mark Millard = wrote: >=20 >> On 2017-Jan-19, at 12:05 PM, Roman Divacky = wrote: >>=20 >>> Type =3D 38 should be R_ABS so thats fine. If what I expected to be = in .got >>> is in .got.plt, what happens if you modify the getPPC64TocBase() to >>> use ::GotPlt instead of ::Got ? >>=20 >> For using GotPlt. . . >>=20 >> -pie use still gets the notices: >>=20 >> can't create dynamic relocation R_PPC64_REL24 against readonly = segment >>=20 >> The log messages do not change at all for GotPlt being in use: Plt, = Got, >> and GotPlt all output the same messages during the compile/link based >> on ld.lld (other options being the same). (I diff'd the outputs.) >>=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. >> 0x00000000100104a0 in .__do_global_ctors_aux () >> (gdb) bt >> #0 0x00000000100104a0 in .__do_global_ctors_aux () >> #1 0x0000000010010508 in ._init () >> #2 0x000000005002ad1c in objlist_call_init (list=3D, = lockstate=3D) at /usr/src/libexec/rtld-elf/rtld.c:2546 >> #3 0x0000000050029fe4 in _rtld (sp=3D, = exit_proc=3D, objp=3D) at = /usr/src/libexec/rtld-elf/rtld.c:673 >> #4 0x00000000500279b0 in ._rtld_start () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:83 >> Backtrace stopped: frame did not save the PC >>=20 >> In other words: the same as when Plt was used. >>=20 >> And the code does not get near executing main. >>=20 >> The difference in: >>=20 >> /usr/local/powerpc64-freebsd/bin/objdump -d --prefix-addresses a.out >>=20 >> output for Got vs. GotPlt is: >> (<: Got, >: GotPlt) >>=20 >> < 0000000010010558 <.plt+0x8> ld r12,32512(r11) >> --- >>> 0000000010010558 <.plt+0x8> ld r12,-32744(r11) >> 346c346 >> < 0000000010010578 <.plt+0x28> ld r12,32520(r11) >> --- >>> 0000000010010578 <.plt+0x28> ld r12,-32736(r11) >> 354c354 >> < 0000000010010598 <.plt+0x48> ld r12,32528(r11) >> --- >>> 0000000010010598 <.plt+0x48> ld r12,-32728(r11) >>=20 >> The GotPlt offset figures look better to me: near the beginning >> of the 64K range with zero offset being near the middle. (That >> does not of itself imply that r11 would be appropriate for the >> figures if the execution got this far.) >>=20 >> Of course the .plt section is far before what you call >> the TOC, unlike in what the bfd linker does. (See below.) >>=20 >> The following includes: >>=20 >> 0x0000000010010550 - 0x00000000100105b0 is .plt >> . . . >> 0x0000000010030020 - 0x0000000010030050 is .got.plt >> 0x0000000010030050 - 0x00000000100300a0 is .toc >> . . . >> 0x000000005005ff00 - 0x000000005005ff08 is .got in = /libexec/ld-elf.so.1 >> . . . >> 0x000000005026f900 - 0x0000000050271f98 is .got in = /lib/libc.so.7 >> 0x0000000050272000 - 0x0000000050277208 is .plt in = /lib/libc.so.7 >>=20 >> (A mix of ld.lld and ld.bfd styles.) >>=20 >> (gdb) info file >> Symbols from "/root/c_tests/a.out". >> Native process: >> Using the running image of child LWP 100168 of process 78109. >> 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 - 0x00000000100104f0 is .text >> 0x00000000100104f0 - 0x000000001001051c is .init >> 0x0000000010010520 - 0x0000000010010544 is .fini >> 0x0000000010010550 - 0x00000000100105b0 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 - 0x0000000050045ab4 is .text in = /libexec/ld-elf.so.1 >> 0x0000000050045ab4 - 0x000000005004856b is .rodata in = /libexec/ld-elf.so.1 >> 0x000000005004856c - 0x000000005004856c 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 _______________________________________________ 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" From owner-freebsd-toolchain@freebsd.org Sat Jan 21 20:19:30 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 C807CCBB432 for ; Sat, 21 Jan 2017 20:19:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-13.reflexion.net [208.70.210.13]) (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 8C7C7945 for ; Sat, 21 Jan 2017 20:19:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18103 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-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: 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 From owner-freebsd-toolchain@freebsd.org Sat Jan 21 22:40:58 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 F3739CBB5F9 for ; Sat, 21 Jan 2017 22:40:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 E2EA3EDD for ; Sat, 21 Jan 2017 22:40:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0LMeuBY062295 for ; Sat, 21 Jan 2017 22:40:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216080] science/bddsolve: fails to build with libc++ 4.0 Date: Sat, 21 Jan 2017 22:40:56 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ed@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: blocked Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sat, 21 Jan 2017 22:40:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216080 Jan Beich (mail not working) changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|216008 | Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216008 [Bug 216008] [exp-run] Update llvm/clang/compiler-rt/libc++/lld/lldb in bas= e to 4.0.0 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Jan 21 23:30:35 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 C738BCBB8C7 for ; Sat, 21 Jan 2017 23:30:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 B67C924B for ; Sat, 21 Jan 2017 23:30:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0LNUZhf078201 for ; Sat, 21 Jan 2017 23:30:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216080] science/bddsolve: fails to build with lang/gcc6 or later Date: Sat, 21 Jan 2017 23:30:35 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ed@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sat, 21 Jan 2017 23:30:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216080 Jan Beich (mail not working) changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|science/bddsolve: fails to |science/bddsolve: fails to |build with libc++ 4.0 |build with lang/gcc6 or | |later --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Jan 21 23:37:43 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 8283ECBBC31 for ; Sat, 21 Jan 2017 23:37:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 71D879F8 for ; Sat, 21 Jan 2017 23:37:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0LNbgwf094716 for ; Sat, 21 Jan 2017 23:37:43 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216316] objcopy in 11 appears to have a regression compared to the version in 10 Date: Sat, 21 Jan 2017 23:37:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sat, 21 Jan 2017 23:37:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216316 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Jan 21 23:40:58 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 04DE3CBBF7E for ; Sat, 21 Jan 2017 23:40:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 E7A1EDFD for ; Sat, 21 Jan 2017 23:40:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0LNev0v000661 for ; Sat, 21 Jan 2017 23:40:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216229] head: (e.g. -r312009): kernel-toolchain: bootstrap-tools stage libllvmminimal can fail for lack of -I options (e.g., from scratch kernel-toolchain) Date: Sat, 21 Jan 2017 23:40:57 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sat, 21 Jan 2017 23:40:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216229 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-toolchain@FreeBSD.o | |rg --=20 You are receiving this mail because: You are the assignee for the bug.=