mailing list of musl libc
 help / color / mirror / code / Atom feed
* regoff_t is broken
@ 2014-07-30 15:09 Jens Gustedt
  2014-07-30 15:53 ` Rich Felker
  2014-07-30 15:55 ` Szabolcs Nagy
  0 siblings, 2 replies; 3+ messages in thread
From: Jens Gustedt @ 2014-07-30 15:09 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]

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.

To summarize the situation,

 - POSIX wants ptrdiff_t or ssize_t for this
 - glibc has int, which happens to be a compliant type on i386, but
    not on x86_64.
 - previously musl had long which works on x86_64 and breaks ABI with
   glibc on i386.
 - 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.

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.

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.

Jens

-- 
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::





[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: regoff_t is broken
  2014-07-30 15:09 regoff_t is broken Jens Gustedt
@ 2014-07-30 15:53 ` Rich Felker
  2014-07-30 15:55 ` Szabolcs Nagy
  1 sibling, 0 replies; 3+ messages in thread
From: Rich Felker @ 2014-07-30 15:53 UTC (permalink / raw)
  To: musl

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: regoff_t is broken
  2014-07-30 15:09 regoff_t is broken Jens Gustedt
  2014-07-30 15:53 ` Rich Felker
@ 2014-07-30 15:55 ` Szabolcs Nagy
  1 sibling, 0 replies; 3+ messages in thread
From: Szabolcs Nagy @ 2014-07-30 15:55 UTC (permalink / raw)
  To: musl

* Jens Gustedt <jens.gustedt@inria.fr> [2014-07-30 17:09:06 +0200]:
> commit 8327ae0cb23b799bc55a45e0d4bd95f5a2b1cdf1
> 
> breaks ABI compatibility with glibc for regexp on x86_64 architectures
> by privileging i386.

yes, glibc is known to be broken on x86_64
i386 has no special priviledge

> 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.

here it is:

http://wiki.musl-libc.org/wiki/Functional_differences_from_glibc#Regular_expressions

there is no specific docs about abi compat afaik


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2014-07-30 15:55 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-30 15:09 regoff_t is broken Jens Gustedt
2014-07-30 15:53 ` Rich Felker
2014-07-30 15:55 ` Szabolcs Nagy

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).