[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 4 Jun 2015 14:14:19 +0200
From: Sebastian Gottschall <s.gottschall@...wrt.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: stable 1.1.9 & current GIT broken on mips
nbd gave me the following patch he found in the IRC. i tested it and its
working
diff --git a/src/ldso/dynlink.c b/src/ldso/dynlink.c
index 42930ad..f498327 100644
--- a/src/ldso/dynlink.c
+++ b/src/ldso/dynlink.c
@@ -270,6 +270,8 @@ static void do_relocs(struct dso *dso, size_t *rel,
size_t rel_size, size_t stri
for (; rel_size; rel+=stride, rel_size-=stride*sizeof(size_t)) {
if (skip_relative && IS_RELATIVE(rel[1])) continue;
type = R_TYPE(rel[1]);
+ if (!type)
+ continue;
sym_index = R_SYM(rel[1]);
reloc_addr = (void *)(base + rel[0]);
if (sym_index) {
Am 04.06.2015 um 06:04 schrieb Rich Felker:
> 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.
