From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6811 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl built with pcc yields segfaults in dynlink.c Date: Wed, 7 Jan 2015 00:33:16 -0500 Message-ID: <20150107053316.GO4574@brightrain.aerifal.cx> References: <20150106074849.GA25889@newbook> <20150106204924.GM4574@brightrain.aerifal.cx> <20150106225647.GA2194@newbook> <20150107005357.GN4574@brightrain.aerifal.cx> <20150107020107.GA2336@newbook> 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 1420608843 1554 80.91.229.3 (7 Jan 2015 05:34:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 7 Jan 2015 05:34:03 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6824-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 07 06:33:59 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 1Y8jFK-00048N-TL for gllmg-musl@m.gmane.org; Wed, 07 Jan 2015 06:33:31 +0100 Original-Received: (qmail 6027 invoked by uid 550); 7 Jan 2015 05:33:29 -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 6017 invoked from network); 7 Jan 2015 05:33:29 -0000 Content-Disposition: inline In-Reply-To: <20150107020107.GA2336@newbook> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6811 Archived-At: On Tue, Jan 06, 2015 at 06:01:10PM -0800, Isaac Dunham wrote: > On Tue, Jan 06, 2015 at 07:53:57PM -0500, Rich Felker wrote: > > On Tue, Jan 06, 2015 at 02:56:50PM -0800, Isaac Dunham wrote: > > > On Tue, Jan 06, 2015 at 03:49:24PM -0500, Rich Felker wrote: > > > > On Mon, Jan 05, 2015 at 11:48:50PM -0800, Isaac Dunham wrote: > > > > > Hello, > > > > > I'm trying to get a pcc-built libc.so that works. > > > > > With the latest PCC, musl builds (lib/libc.so) and the result will display > > > > > the proper messages if run from the command line without arguments. > > > > > However, if I try to run a program with it > > > > > (even via -Wl,-dynamic-linker,`pwd`/lib/libc.so), I get a segfault > > > > > in src/ldso/dynlink.c: > > > > > (gdb) where > > > > > #0 sysv_hash (s0=0x0, s0=0x0) at src/ldso/dynlink.c:177 > > > > > #1 0xb7f6f747 in find_sym (dso=0xbffffb18, rel=0xb7ffe1d4 <.L1502>, > > > > > rel_size=, stride=, dso=0xbffffb18, > > > > > rel=0xb7ffe1d4 <.L1502>, rel_size=, stride=) > > > > > at src/ldso/dynlink.c:251 > > > > > #2 0xb7f6f916 in do_relocs () at src/ldso/dynlink.c:308 > > > > > Backtrace stopped: frame did not save the PC > > > > > > > > > > I'm using Alpine Linux edge, recently updated, with linux-vanilla. > > > > > > > > It would be helpful to see the readelf -a output for libc.so and the > > > > binary using it, and whatever information gdb can give on the value of > > > > local vars at each of the above call frames. > > > > > > Attaching a tar.xz containing the output of: > > > - readelf -a lib/libc.so: libc-pcc.readelf > > > - readelf -a a.out: argvname.readelf > > > - echo -e 'run\nwhere\nbt full' |gdb ./a.out: argvname.gdb > > > (which is substantially similar to the output for "lib/libc.so ./a.out") > > > - and the source for a.out: argvname.c > > > > > > It's 51k, so I'm hoping it gets through. > > > > It came through fine, but I suspect the debug info is bogus. The > > values being shown don't seem to make sense. It might help more to > > show the disassembly at eip and the value of all registers, or to post > > the binaries somewhere I could download and analyze them. I looked at > > the readelf outputs and didn't see any invalid relocs immediately, so > > I'm not sure what's happening. > > https://www.dropbox.com/s/gfakdgdg4i1n85j/libc.tar.xz?dl=1 > > As far as I can tell, there's no reason to use the particular program > I'm testing with; it just happens to be a trivial program I had. So far I haven't been able to make any sense of the crash. The debug info produced by pcc is utter nonsense, or at least not what gdb is expecting; the symbolic information it's printing is all wrong, and trying to set breakpoints even crashes my gdb. The size of the do_relocs stack frame looks wrong too; the arguments for find_sym and subsequent stuff on the stack looks closer to do_relocs' return address than it should be. I wonder if pcc is generating bogus code for functions which return structures... Rich