From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5678 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: regoff_t is broken Date: Wed, 30 Jul 2014 11:53:11 -0400 Message-ID: <20140730155311.GL1674@brightrain.aerifal.cx> References: <1406732946.4695.372.camel@eris.loria.fr> 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 1406735611 23704 80.91.229.3 (30 Jul 2014 15:53:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Jul 2014 15:53:31 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5683-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 30 17:53:27 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XCWBx-0001WU-EG for gllmg-musl@plane.gmane.org; Wed, 30 Jul 2014 17:53:25 +0200 Original-Received: (qmail 13851 invoked by uid 550); 30 Jul 2014 15:53:24 -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 13843 invoked from network); 30 Jul 2014 15:53:24 -0000 Content-Disposition: inline In-Reply-To: <1406732946.4695.372.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5678 Archived-At: On Wed, Jul 30, 2014 at 05:09:06PM +0200, Jens Gustedt wrote: > Hi, > perhaps I have missed a discussion on that. > > commit 8327ae0cb23b799bc55a45e0d4bd95f5a2b1cdf1 > > breaks ABI compatibility with glibc for regexp on x86_64 architectures > by privileging i386. This commit didn't change anything with regard to the issue you're experiencingx. The x86_64 definition was mismatching with glibc's definition both before and after the commit. > To summarize the situation, > > - POSIX wants ptrdiff_t or ssize_t for this Strictly speaking, POSIX just wants a signed type that is wide enough to store the positive range of ptrdiff_t and ssize_t. It need not be the same as either of these. > - glibc has int, which happens to be a compliant type on i386, but > not on x86_64. Right. > - previously musl had long which works on x86_64 and breaks ABI with > glibc on i386. It actually only affected the C++ ABI, unless you want to consider different types with same size, representation, and argument passing convention an ABI issue. It was changed for compatibility with the C++ ABI from glibc (but obviously only on 32-bit archs, since on 64-bit glibc has a broken definition). > - now musl has _Addr which is POSIXLY ok on i386 but breaks glibc ABI > on x86_64. > > I wonder if there are no other ways around this. There's no way around it without a wrapper library or compatibility layer in the loader. glibc's type is just wrong. I have an open bug report on it requesting that they fix the type and bump the version on regexec, but it hasn't gotten any attention: https://sourceware.org/bugzilla/show_bug.cgi?id=12900 marked duplicate of: https://sourceware.org/bugzilla/show_bug.cgi?id=5945 > Also, I think there should be big flash lights somewhere that make > linking musl against a program that was compiled with glibc regex > impossible or so. Where would you suggest putting this warning? Eventually status/level of glibc binary compatibility should be in the manual, but I haven't gotten that far in the manual. The wiki is an easy place to put it for now but it might not get noticed by users. Of course wherever we advertise limited level of glibc ABI compatibility, we could and probably should have a link to such caveats, wherever they're documented. > Unfortunately that broke my code in a way that was really hard to > trace. The musl type being wider than the glibc type, I got a > corrupted my stack somewhere near the start of my application. Did > cost me a day or so to find out where that came from. Support for using glibc-linked binaries with musl is incomplete, but I agree this should be better-documented somewhere. Rich