Re: Broken silent glibc-specific assumptions uncovered by musl

[Rich Felker <dalias@aerifal.cx>]

On Sun, May 19, 2013 at 12:51:47AM +0200, Szabolcs Nagy wrote:
> > > - relying on LD_* or other env vars for glibc or the loader
> > 
> > We do support the main ones that could be used reasonably by
> > applications: LD_PRELOAD and LD_LIBRARY_PATH. Most of the others are
> > for debugging/"audit" stuff, I think.
> > 
> 
> yes other ld_ stuff does not seem useful
> 
> there are many envvars used by glibc, eg now i found these:
> [...]
> CHARSET (toutf8)

What is toutf8? (Just curious)

> DATEMSK (getdate)

This is POSIX and supported by musl. :)

> MSGVERB (fmtmsg)
> SEV_LEVEL (fmtmsg)

I believe these are standard too, but we presently don't have fmtmsg.
It's one of the few missing XSI interfaces.

> RESOLV_* (resolv)
> RES_OPTIONS (resolv)
> HOSTALIASES (resolv)
> LOCALDOMAIN (resolv)

Some of these may be desirable at some point.

> NLSPATH (catgets)

I believe this is standard too.

> > > - using constructors with priority gcc extension
> > 
> > Do you know if musl just ignores the order, or fails to run them at
> > all?
> > 
> 
> ok, the priority is solved by the linker and musl runs them
> 
> here (i386) constructors are put into .ctors.* sections
> which get sorted by the linker

How does this work for dynamic linking? Is priority only respected
within a single DSO, and not between multiple DSOs?

> on arm they are put into .init_array.*
> 
> it seems the linker and glibc support mixing these:
> the order in which init things are run is
> 
>  preinit_array
>  ctors (priority sorted by the linker)
>  init_array (priority sorted by the linker)
> 
> on i386 i have to explicitly request something to get
> into an .init_array section, and then it will be run
> by glibc but not by musl
> 
> i think musl does not support .preinit_array at all
> 
> these are probably rarely used features

Yes, at some point we should probably revisit this. In addition, it
seems that the init_array stuff might eventually be used on more and
more archs, so we might need to investigate whether there's a way to
write the code for calling it in C rather than asm, and then somehow
merge the C and asm object files when generating crti.o and crtn.o...

Unfortunately, however, I'm skeptical of whether this can give
reasonable code generation that works for both PIC(PIE) and non-PIC
cases...

> > > - ppc double-double long double
> > 
> > I really doubt anyone depends on this or even wants it.. but is ppc
> > really using double-double still? The gcc docs make it sound like they
> > switched to IEEE quad when they made long double 128-bit, ignoring
> > what IBM did, but the glibc people seem to consider it double-double.
> 
> yes, i dont think ppl depend on this but you can never know
> 
> some applications may have different behaviour under
> a glibc ld128ibm/ld128ieee toolchain vs a musl ld64 toolchain

I think for this list, if we're going to publish it, we should focus
on glibc-specific assumptions that were actually found in practice.
Bringing in lots of theoretical ones just adds doubt to whether musl
will meet people's needs, and unless they're clearly marked and
separated from the issues we actually found, I think it makes the list
less informative -- the fact that we actually found certain types of
problems, rather than just reasoning about ones that might arise, is
in many ways the most informative aspect of the list. Of course, it
could be supplemented by an additional list of more theoretical
considerations.

Rich