Date: Thu, 4 Jun 2015 00:04:02 -0400 From: Rich Felker <dalias@...c.org> To: Sebastian Gottschall <s.gottschall@...wrt.com> Cc: musl@...ts.openwall.com Subject: Re: stable 1.1.9 & current GIT broken on mips 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
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.