[Qemu-devel] qemu & arm eabi (armel)

[Qemu-devel] qemu & arm eabi (armel)

[K. Richard Pixley]

Does anyone have qemu running in user emulation with arm eabi, (armel), 
traps?

I can get qemu-system booting an armel system.  And I can get qemu-user 
running with the codesourcery gcc-3 eabi libc's, (ie, the ones with the 
codesourcery kernel call "shims"), but I haven't gotten it working yet 
with eabi kernel calls in user mode.

Should this be expected to work in 0.8.2?

--rich

Re: [Qemu-devel] qemu & arm eabi (armel)

[Rafael Espíndola]

On 9/26/06, K. Richard Pixley <rich.pixley@palmsource.com> wrote:
> Does anyone have qemu running in user emulation with arm eabi, (armel),
> traps?

I am hunting some strange asserts failures in ld.so, but it is mostly
working. It is a maemo 2.0 rootstrap that I am using.

Best Regards,
Rafael

Re: [Qemu-devel] qemu & arm eabi (armel)

[Paul Brook]

On Tuesday 26 September 2006 22:26, K. Richard Pixley wrote:
> Does anyone have qemu running in user emulation with arm eabi, (armel),
> traps?

EABI works fine, however NPTL does not.

http://lists.gnu.org/archive/html/qemu-devel/2006-09/msg00194.html

Paul

Re: [Qemu-devel] qemu & arm eabi (armel)

[K. Richard Pixley]

Ok, then I'm confused because I'm seeing dumps just trying to run a null 
program.  Unless there's NPTL setup stuff in crt0, I can't guess what 
might be going on yet.  This same null binary runs on a qemu-system with 
suitable rootfs & kernel.

--rich

rpixley@svrpixleylnx> ./qemu-arm --version
qemu-arm version 0.8.2, Copyright (c) 2003-2005 Fabrice Bellard
[...]
rpixley@svrpixleylnx> ./qemu-arm ./null
qemu: uncaught target signal 11 (Segmentation fault) - exiting

Re: [Qemu-devel] qemu & arm eabi (armel)

[Paul Brook]

On Tuesday 26 September 2006 23:14, K. Richard Pixley wrote:
> Ok, then I'm confused because I'm seeing dumps just trying to run a null
> program.  Unless there's NPTL setup stuff in crt0, I can't guess what
> might be going on yet.  This same null binary runs on a qemu-system with
> suitable rootfs & kernel.

The glibc startup code contains TLS initialisation that will fail on unpatched 
qemu. If you have applied the TLS patch there are a couple of other things 
that could cause problems:

- Make sure it's picking up the correct target shared libraries (or link your 
test application statically).
- Try configuring qemu with --static. The default (building qemu as a shared 
library) seems to cause strange problems on many systems.
- Make sure uname -r reports at least 2.6.16 (qemu can lie for you).

Paul

Re: [Qemu-devel] qemu & arm eabi (armel)

[K. Richard Pixley]

[-- Attachment #1: Type: text/plain, Size: 1173 bytes --]

Paul Brook wrote:
> On Tuesday 26 September 2006 23:14, K. Richard Pixley wrote:
>   
>> Ok, then I'm confused because I'm seeing dumps just trying to run a null
>> program.  Unless there's NPTL setup stuff in crt0, I can't guess what
>> might be going on yet.  This same null binary runs on a qemu-system with
>> suitable rootfs & kernel.
>>     
> The glibc startup code contains TLS initialisation that will fail on unpatched 
> qemu. If you have applied the TLS patch there are a couple of other things 
> that could cause problems:
>
> - Make sure it's picking up the correct target shared libraries (or link your 
> test application statically).
>   
Done.
> - Try configuring qemu with --static. The default (building qemu as a shared 
> library) seems to cause strange problems on many systems.
>   
Done.
> - Make sure uname -r reports at least 2.6.16 (qemu can lie for you).
>   
Ah.  Hm..  ubuntu-5 is currently:

rpixley@svrpixleylnx> uname -a
Linux svrpixleylnx 2.6.12-10-686-smp #1 SMP Tue Jul 18 23:03:01 UTC 2006 
i686 GNU/Linux

Do you know why 2.6.16 would be required?  (I'll see if I can't 
find/build a 2.6.16 system on which to try it today.)

--rich

[-- Attachment #2: Type: text/html, Size: 1837 bytes --]

Re: [Qemu-devel] qemu & arm eabi (armel)

[Paul Brook]

> Do you know why 2.6.16 would be required?  (I'll see if I can't
> find/build a 2.6.16 system on which to try it today.)

Because arm-linux didn't get EABI support until 2.6.16 (though our toolchains 
may accept 2.6.14). glibc has santity checks stop applications even trying to 
run on kernels that are too old.

As I mentioned qemu lie about the kernel version. See -r 
and --enable-uname-release.

Paul

Re: [Qemu-devel] qemu & arm eabi (armel)

[K. Richard Pixley]

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]

Paul Brook wrote:
>> Do you know why 2.6.16 would be required?  (I'll see if I can't
>> find/build a 2.6.16 system on which to try it today.)
>>     
> Because arm-linux didn't get EABI support until 2.6.16 (though our toolchains 
> may accept 2.6.14). glibc has santity checks stop applications even trying to 
> run on kernels that are too old.
>
> As I mentioned qemu lie about the kernel version. See -r 
> and --enable-uname-release.
I'm confused.  My host kernel, (hosted on an x86 ubuntu box), is:

rpixley@svrpixleylnx> uname -r
2.6.12-10-686-smp

And my understanding is that there is no kernel when running qemu-user 
because qemu is emulating the kernel calls.

What am I missing?  Or where does the kernel version come into play?

--rich

[-- Attachment #2: Type: text/html, Size: 1183 bytes --]

Re: [Qemu-devel] qemu & arm eabi (armel)

[Paul Brook]

On Wednesday 27 September 2006 19:27, K. Richard Pixley wrote:
> Paul Brook wrote:
> >> Do you know why 2.6.16 would be required?  (I'll see if I can't
> >> find/build a 2.6.16 system on which to try it today.)
> >
> > Because arm-linux didn't get EABI support until 2.6.16 (though our
> > toolchains may accept 2.6.14). glibc has santity checks stop applications
> > even trying to run on kernels that are too old.
> >
> > As I mentioned qemu lie about the kernel version. See -r
> > and --enable-uname-release.
>
> I'm confused.  My host kernel, (hosted on an x86 ubuntu box), is:
>
> rpixley@svrpixleylnx> uname -r
> 2.6.12-10-686-smp
>
> And my understanding is that there is no kernel when running qemu-user
> because qemu is emulating the kernel calls.
>
> What am I missing?  Or where does the kernel version come into play?

glibc startup code checks the kernel version. If the reported version is 
earlier than the version it was compiled for it will terminate.
When building glibc you specify a kernel version, and glibc will leave out 
backwards compatibility code for older kernels. The runtime check is a sanity 
check. It's generally better for the application to die immediately than fail 
subtly later on.

Of course when using qemu the syscalls thatqemu emulates tend to be more 
important than the host kernel version.  By default qemu will report the same 
version as the host kernel. However you can tell it to report a different 
version.

Paul

Re[2]: [Qemu-devel] qemu & arm eabi (armel)

[Paul Sokolovsky]

Hello Paul,

Wednesday, September 27, 2006, 9:38:57 PM, you wrote:

> On Wednesday 27 September 2006 19:27, K. Richard Pixley wrote:

[]

> Of course when using qemu the syscalls thatqemu emulates tend to be more
> important than the host kernel version.  By default qemu will report the same
> version as the host kernel. However you can tell it to report a different
> version.

  Excuse me for stupid question, but how? I hit that issue some time
ago, and ended up patching glibc. Now it is here again, and I again
did qemu-arm --help, read the doc, grepped it, etc. And well, IIRC, on
that first occasion I even looked at the qemu source, to see if it can
do that. All in vain. What did I miss?

> Paul


Thanks,

-- 
 Paul                            mailto:pmiscml@gmail.com

Re: [Qemu-devel] qemu & arm eabi (armel)

[Paul Brook]

> > Of course when using qemu the syscalls thatqemu emulates tend to be more
> > important than the host kernel version.  By default qemu will report the
> > same version as the host kernel. However you can tell it to report a
> > different version.
>
>   Excuse me for stupid question, but how?

As I mentined in an earlier mail, you can use the -r qemu commandline option, 
or configure qemu with --enable-uname-release.

Paul