[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 30 Jul 2014 11:53:11 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: regoff_t is broken
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
