Re: stable 1.1.9 & current GIT broken on mips

[Rich Felker <dalias@libc.org>]

On Tue, Jun 02, 2015 at 09:59:08PM +0200, Sebastian Gottschall wrote:
> Am 02.06.2015 um 21:11 schrieb Rich Felker:
> >On Tue, Jun 02, 2015 at 07:52:15PM +0200, Sebastian Gottschall wrote:
> >>Am 02.06.2015 um 19:19 schrieb Rich Felker:
> >>>On Tue, Jun 02, 2015 at 05:57:23PM +0200, Sebastian Gottschall wrote:
> >>>>Hello
> >>>>
> >>>>i tested today the current 1.1.9 (and later also current git so see
> >>>>if its the same behaviour)
> >>>>build on a mipsr2 big endian target (atheros ar7xxx) based on my
> >>>>dd-wrt firmware.
> >>>>i found out that mips seems to be broken on musl right now. the
> >>>>behaviour is
> >>>>that a call using execvp will not result in calling the desired
> >>>>application.
> >>>>on a second call and a following return call, the userspace will
> >>>>lock up with no way todo anything anymore.
> >What do you mean by "the userspace will lock up"? The process hangs?
> >Or the whole system? Is there any way to observe what's going on with
> >strace?
> no serial input anymore, looks like system hangs. but sometimes a
> kernel message still may race up. ([81.730000] random: nonblocking
> pool is initialized for instance)
> so its not completelly dead, but its not possible
> to interface from userspace anymore with serial console etc.

Can you provide me with the libc.so binary that's failing?

> >And can you clarify what you mean about execvp? Are you saying the
> >first call to execvp returns with an error? I don't get what you mean
> >about "a second call and a following return call". On success execvp
> >does not return.
> i never checked for a return value. i just can say that the programm
> was never called.
> see the function i provided
> _eval("devinit"); //returns, but app never gets called
> _eval("sysinit"); //app never gets called, _eval hangs complete
> system on return call of _eval
> >
> >If you're trying to start a dynamic-linked application, it's likely
> >that something is going wrong in the dynamic linker after execvp
> >succeeds but before execution passes into the main program. You could
> >try running a program with global constructors and see if they run.
> >There's a jump at the end of dynamic linking which is not compatible
> >with calling into mips16 code, but as long as crt1.o is not mips16
> >(and it shouldn't be; on mips it's still built from a .s file, and you
> >said you're not using mips16 in libc) this should not be a problem.
> >
> >Another possibility I should mention since this is DD-WRT is that
> >you've got an ancient kernel that's not compatible with TLS. As of
> >1.1.0 musl deprecated running without a valid thread pointer, but
> >still worked if you happened not to invoke code that needs it. 1.1.9
> >removed the last remnants of support for no-thread-pointer and now
> >aborts with SIGSEGV or SIGILL in the startup code if setting the
> >thread pointer fails, which will be the case on 2.4 kernels.
> its kernel 3.18 and kernel 3.10 which is mainly used. in the
> testcase 3.18 was used
> dont think that dd-wrt still used 2.4 (this is only the case for old
> wrt54g devices, but these devices are uclibc based)
> musl is the standard for all mips and armbe/le based devices in
> dd-wrt only y86,x64,powerpc and mips64 devices are still using
> uclibs since mips64 doesnt work with musl and power
> wasnt working months ago. may have changed in between. never tested so far.
> but target is to use musl on all cpu architectures in future, once
> its working on all.

OK, that's not the issue then.

Rich