musl bug or not, real or not? (Was: [musl] Update: [musl] pthread_getattr_np() vs explicit runtime) loader

[u-uy74@aetey.se]

Either nobody cares or nobody has a gcc-5.x toolchain built with musl?
Wondering.

gcc-5 looks like a case important enough to care.

Rune

On Wed, Sep 30, 2015 at 10:35:48PM +0200, u-uy74@aetey.se wrote:
> On Wed, Sep 30, 2015 at 05:43:37PM +0200, u-uy74@aetey.se wrote:
> > 
> > I still think that the crashes are caused by errors
> > while guessing the stack placement in pthread_getattr_np(),
> > simply because of the kernel doing something else than usual.
> 
> I can reproduce the problem and this looks like something
> to fix or at least work around, either in gcc or in musl.
> 
> Running with the implicit loader works, but using the explicit one yields:
> 
> ----------------------------------------------------------------
> # cat /proc/sys/kernel/randomize_va_space
> 2
> 
> $ /pathtomusllibc.so --library-path /pathtogcc-5libs /pathto/jv-convert --help
> Usage: jv-convert [OPTIONS] [INPUTFILE [OUTPUTFILE]]
> 
> Convert from one encoding to another.
> 
>    --encoding FROM
>    --from FROM        use FROM as source encoding name
>    --to TO            use TO as target encoding name
>    -i FILE            read from FILE
>    -o FILE            print output to FILE
>    --reverse          swap FROM and TO encodings
>    --help             print this help, then exit
>    --version          print version number, then exit
> 
> `-' as a file name argument can be used to refer to stdin or stdout.
> 
> # echo 0 > /proc/sys/kernel/randomize_va_space
> 
> $ /pathtomusllibc.so --library-path /pathtogcc-5libs /pathto/jv-convert --help
> Segmentation fault
> ----------------------------------------------------------------
> 
> Would anybody try this and confirm or refute?
> 
> Rune