From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7689 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: ppc soft-float regression Date: Mon, 18 May 2015 16:10:43 -0400 Message-ID: <20150518201043.GX17573@brightrain.aerifal.cx> References: <20150517080321.GL16123@waldemar-brodkorb.de> <20150517100218.GA2754@euler> <20150517163723.GP17573@brightrain.aerifal.cx> <20150517175021.GA2171@euler> <20150517181556.GA23050@euler> <20150517195622.GA4761@euler> <20150518183929.GA6370@euler> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1431979865 17417 80.91.229.3 (18 May 2015 20:11:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 May 2015 20:11:05 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7701-gllmg-musl=m.gmane.org@lists.openwall.com Mon May 18 22:10:58 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YuRNK-0007b6-Fn for gllmg-musl@m.gmane.org; Mon, 18 May 2015 22:10:58 +0200 Original-Received: (qmail 32015 invoked by uid 550); 18 May 2015 20:10:56 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 31997 invoked from network); 18 May 2015 20:10:56 -0000 Content-Disposition: inline In-Reply-To: <20150518183929.GA6370@euler> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7689 Archived-At: On Mon, May 18, 2015 at 08:39:30PM +0200, Felix Janda wrote: > Something seems to be wrong with the powerpc copy relocations. > > Attached is a binary for testing (qemu-ppc works fine). It is compiled > from > > > #include > > extern char **environ; > > int main(int argc, char **argv) > { > printf("%p %p\n", environ, &argv[argc + 1]); > return 0; > } > > > Output before dynamic linker overhaul: > > 0xf6f4f830 0xf6f4f830 > > and after: > > 0 0xf6f4f830 > > > It seems to me that the dynamic linker indeed copies environ, which is > 0 at that point, but that __init_libc uses the old location of environ. OK I've looked at this and I understand what's happening. PowerPC does not have a separate relocation type for GOT entries; instead it uses the same relocation type used for address constants global data. These do not get re-processed after the main program and libraries are added, because unlike GOT slots, they have addends, and if the addend is inline (using REL rather than RELA) then it's already been clobbered by the early relocation phase and can't easily be recovered. I see three possible solutions: 1. Treat R_PPC_ADDR32 as a GOT relocation instead of a regular symbolic relocation in data. This would suppress the addend (giving wrong address) if inline addends (REL) were used, but in practice powerpc aways uses RELA. I consider this a hack, and perhaps risky, since in principle someone could make powerpc binaries with REL. 2. Re-process not just GOT type relocs, but also any RELA (non-inline-addend) relocs again on the second pass. This would work as long as powerpc only uses RELA, and if REL is ever used, the worst that would happen is the current bug (losing environ, etc.) rather than silently wrong relocations in global data. This approach is not a hack, but I consider it something of an incomplete fix. 3. Re-process all symbolic relocations. For REL-type (inline addend), we have to recover the original addend, which can be done by calling find_sym again, but using ldso instead of the current library chain head as the context to search for the symbol in, then subtracting the resulting address to get back the original addend. I like the third solution best, even though it incurs a small code size cost and a performance cost for archs using REL, because it's completely robust against any weird ways some archs might end up using relocations. The expected number of such relocations is tiny anyway; on my i386 builds it's 14. If option 3 proves to be difficult or costly, however, we could consider option 2 as a temporary measure to get powerpc working. It wouldn't even need to be reverted, because option 3 includes/subsumes the work that would be done for option 2. Rich