From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14852 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: another armv7-m exception handling problem Date: Mon, 21 Oct 2019 15:29:37 -0400 Message-ID: <20191021192937.GJ16318@brightrain.aerifal.cx> References: <20191021180956.GQ7832@port70.net> <20191021190318.GI16318@brightrain.aerifal.cx> <20191021190857.GR7832@port70.net> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="112254"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14868-gllmg-musl=m.gmane.org@lists.openwall.com Mon Oct 21 21:29:53 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iMdNI-000T0x-MP for gllmg-musl@m.gmane.org; Mon, 21 Oct 2019 21:29:52 +0200 Original-Received: (qmail 21802 invoked by uid 550); 21 Oct 2019 19:29:50 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 21784 invoked from network); 21 Oct 2019 19:29:49 -0000 Content-Disposition: inline In-Reply-To: <20191021190857.GR7832@port70.net> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14852 Archived-At: On Mon, Oct 21, 2019 at 09:08:57PM +0200, Szabolcs Nagy wrote: > * Rich Felker [2019-10-21 15:03:18 -0400]: > > On Mon, Oct 21, 2019 at 08:09:56PM +0200, Szabolcs Nagy wrote: > > > * Patrick Oppenlander [2019-10-21 15:43:40 +1100]: > > > > Not sure if this is a musl, gcc or ld bug. > > > > > > > > Running gcc-8.3.0 musl 1.1.24 static pie. > > > > > > providing binutils version number is useful if there is > > > a chance that it's an ld bug. > > > > > > this seems to be > > > https://sourceware.org/bugzilla/show_bug.cgi?id=22269 > > > > > > which was supposed to be fixed by > > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=95b03e4ad68e7a90f5096b47df595636344b783a > > > > > > but apperently there are still missing cases. > > > (it does not help that the ld test for this bug > > > greps for R_*_NONE dynrelocs but not R_*_RELATIVE > > > which i is just as bad for undef weak syms in pie) > > > i added a note to the bug. > > > > > > if you add __attribute__((visibility("hidden"))) > > > to the example given by Rich then it works, the > > > bug only affects static pie linking. > > > > That's really weird. How does it end up having an outstanding > > *relative* relocation when it's not defined locally? I could > > understand having a bogus outstanding symbolic one, but relative makes > > no sense and suggests ld is doing something very wrong... > > i'd guess it creates a relative reloc for every > got entry that stores some symbol's address > which is known to be local, which makes sense, > except for undefined weak symbols which should > have fixed 0 address. > > and i'd guess there is some logic that special > cases local undef weak in pic so hidden works, > and that check should be extended to cover the > static pie case. In 2.33.1, the offending code (creating the bad relative relocation) is at line 11637. It's possible some earlier code path leading to it is wrong, around line 11515 or so, but I think there just needs to be an extra else path before this one that covers undefined/undefweak. Rich