[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 1 Oct 2018 01:11:15 +0200
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: musl@...ts.openwall.com
Subject: Re: broken shared executables on armeb (illegal instruction)
Hey Rich,
Thanks for the insight.
On Mon, Oct 1, 2018 at 12:24 AM Rich Felker <dalias@...c.org> wrote:
> > $ printf '#include <stdio.h>\nint main(){puts("hello world");}' | bin/musl-gcc -xc -o helloworld $CFLAGS -
> > /usr/libexec/gcc/armeb-pc-linux-gnueabi/ld: /usr/lib/gcc/armeb-pc-linux-gnueabi/8.2.0/libgcc.a(_dvmd_lnx.o): in function `__aeabi_idiv0':
> > /var/tmp/portage/cross-armeb-pc-linux-gnueabi/gcc-8.2.0-r3/work/gcc-8.2.0/libgcc/config/arm/lib1funcs.S:1545: undefined reference to `raise'
> > collect2: error: ld returned 1 exit status
> > [This appears to be a well-known bug in some other mailing list post. Working around with the next command:]
>
> This looks like you're trying to dynamic-link anyway...?
Yes. It's this old "bug", fwiw: https://www.openwall.com/lists/musl/2018/05/09/1
>
> Overriding the ABI seems like a really bad idea. What ABI is your
> toolchain defaulting to?
Good thinking: armv5. Though notably I don't have the same issue with
little endian. And passing '-cpu cortex-a15' or the like to qemu-user
doesn't fix that. Maybe I'll ask around over on the qemu mailing list,
though.
However:
> Have you fun with -singlestep -d in_asm,nochain so you can see what
> instruction it faults on?
Interestingly, when in armv5 mode, it works fine and the disassembly
looks correct. But when in armv7 mode, it seems to be interpreting all
of the instructions in the wrong endian, right up to the failing one:
----------------
IN:
0xff79561c: 00b0a0e3 adcseq sl, r0, r3, ror #1
----------------
IN:
0xff795620: 00e0a0e3 rsceq sl, r0, r3, ror #1
----------------
IN:
0xff795624: 10109fe5 andsne r9, r0, r5, ror #31
----------------
IN:
0xff795628: 01108fe0 tsteq r0, r0, ror #31
----------------
IN:
0xff79562c: 0d00a0e1 stceq 0, cr10, [r0, #-900]
So this looks like what's actually happening is gcc goes into -mbe8
mode with armv7-a, which is to be expected. But QEMU is always in BE32
mode. Passing -mbe32 to the cflags "fixes" the issue, though it's
still unclear how to run BE8 code in qemu. But anyway, it's clear this
is probably not a musl issue anymore at this point. So thanks for the
pointer.
The real issue I'm facing is not being able to start a userland in the
kernel in big endian mode, and this persists even using the above
tricks (-mbe8 and -march=armv5 and so forth). I'll keep plugging away,
but indeed this probably isn't musl related.
Thanks again,
Jason
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.
