[Qemu-devel] linux-user/arm unsupported syscalls

[Qemu-devel] linux-user/arm unsupported syscalls

[Jan-Simon Möller]

Hi!

I'm running some debian-lenny/arm binaries in user-mode emulation and get these 2 messages:

qemu: Unsupported ARM syscall: 0x9000e5
qemu: Unsupported ARM syscall: 0x9000e2


Any are these known already ? It doesn't seem critical as execution continues.

Best,
Jan-Simon

Re: [Qemu-devel] linux-user/arm unsupported syscalls

[Martin Mohring]

Jan-Simon Möller wrote:
> Hi!
>
> I'm running some debian-lenny/arm binaries in user-mode emulation and get these 2 messages:
>
> qemu: Unsupported ARM syscall: 0x9000e5
> qemu: Unsupported ARM syscall: 0x9000e2
>
>
> Any are these known already ? It doesn't seem critical as execution continues.
>
> Best,
> Jan-Simon
>   
Does anybody here know what the 0x9 number in front of e5 and e2 means?
When such an error comes in qemu, for me usually a decimal number of a
syscall from any of the "linux-user/<arch>/syscall_nr.h file is printed.
But not a hexnumber with 0x9000 in front....

Martin

Re: [Qemu-devel] linux-user/arm unsupported syscalls

[Riku Voipio]

On Thu, Jan 22, 2009 at 09:37:15PM +0100, Martin Mohring wrote:
> Jan-Simon Möller wrote:
> > Hi!
> >
> > I'm running some debian-lenny/arm binaries in user-mode emulation and get these 2 messages:

debian/arm or debian/armel ? Which specific binaries?

> > qemu: Unsupported ARM syscall: 0x9000e5
> > qemu: Unsupported ARM syscall: 0x9000e2

> Does anybody here know what the 0x9 number in front of e5 and e2 means?

oldabi syscalls.

> When such an error comes in qemu, for me usually a decimal number of a
> syscall from any of the "linux-user/<arch>/syscall_nr.h file is printed.
> But not a hexnumber with 0x9000 in front....

Because the error is being printed from a place than usual. Qemu appears
to think the binary is eabi and is thus not reducing 0x900000 as usual
when running oldabi binaries.

The warned syscalls (setxattr, getattr) go usually via the
unimplemented_nowarn path, so no warning should be visible for users.

-- 
"rm -rf" only sounds scary if you don't have backups

Re: [Qemu-devel] linux-user/arm unsupported syscalls

[Jan-Simon Möller]

Am Thursday 22 January 2009 22:04:06 schrieb Riku Voipio:
> On Thu, Jan 22, 2009 at 09:37:15PM +0100, Martin Mohring wrote:
> > Jan-Simon Möller wrote:
> > > Hi!
> > >
> > > I'm running some debian-lenny/arm binaries in user-mode emulation and get these 2 messages:
> 
> debian/arm or debian/armel ? Which specific binaries?
maemo with some bits of debian/armel
 
> > > qemu: Unsupported ARM syscall: 0x9000e5
> > > qemu: Unsupported ARM syscall: 0x9000e2
> 
> > Does anybody here know what the 0x9 number in front of e5 and e2 means?
> 
> oldabi syscalls.
> 
> > When such an error comes in qemu, for me usually a decimal number of a
> > syscall from any of the "linux-user/<arch>/syscall_nr.h file is printed.
> > But not a hexnumber with 0x9000 in front....
> 
> Because the error is being printed from a place than usual. Qemu appears
> to think the binary is eabi and is thus not reducing 0x900000 as usual
> when running oldabi binaries.
> 
> The warned syscalls (setxattr, getattr) go usually via the
> unimplemented_nowarn path, so no warning should be visible for users.
> 

Ok, setxattr, getarr are file-operations ? Need to dig what's the reason.

Best,
Jan-Simon

Re: [Qemu-devel] linux-user/arm unsupported syscalls

[Riku Voipio]

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

On Fri, Jan 23, 2009 at 10:54:09AM +0100, Jan-Simon Möller wrote:
> > debian/arm or debian/armel ? Which specific binaries?
> maemo with some bits of debian/armel

That's hardly "specific binaries", but with my voodoo remote debugging
skillz I think I managed to trace this down. The libattr/libacl you are
using is missing this patch:

http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=attr-2.4.32-armel.diff;att=1;bug=421627

-- 
"rm -rf" only sounds scary if you don't have backups

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Qemu-devel] linux-user/arm unsupported syscalls

[Jan-Simon Möller]

Am Wednesday 28 January 2009 16:22:02 schrieb Riku Voipio:
> On Fri, Jan 23, 2009 at 10:54:09AM +0100, Jan-Simon Möller wrote:
> > > debian/arm or debian/armel ? Which specific binaries?
> > maemo with some bits of debian/armel
> 
> That's hardly "specific binaries", but with my voodoo remote debugging
> skillz I think I managed to trace this down. The libattr/libacl you are
> using is missing this patch:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=attr-2.4.32-armel.diff;att=1;bug=421627
> 

Great stuff - i looked into maemo libattr and libacl .
http://repository.maemo.org/pool/diablo/free/a/acl/
http://repository.maemo.org/pool/diablo/free/a/attr/

And yes, its missing in attr.

voodoo ;)

skills +1

Best,
Jan-Simon

Re: [Qemu-devel] linux-user/arm unsupported syscalls

[Martin Mohring]

Jan-Simon Möller wrote:
> Am Wednesday 28 January 2009 16:22:02 schrieb Riku Voipio:
>   
>> On Fri, Jan 23, 2009 at 10:54:09AM +0100, Jan-Simon Möller wrote:
>>     
>>>> debian/arm or debian/armel ? Which specific binaries?
>>>>         
>>> maemo with some bits of debian/armel
>>>       
>> That's hardly "specific binaries", but with my voodoo remote debugging
>> skillz I think I managed to trace this down. The libattr/libacl you are
>> using is missing this patch:
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=attr-2.4.32-armel.diff;att=1;bug=421627
>>
>>     
>
> Great stuff - i looked into maemo libattr and libacl .
> http://repository.maemo.org/pool/diablo/free/a/acl/
> http://repository.maemo.org/pool/diablo/free/a/attr/
>
> And yes, its missing in attr.
>
> voodoo ;)
>
> skills +1
>
> Best,
> Jan-Simon
Cool. What do you suggest? I could build a new qemu snapshot with that
fixed. Will you consider this for qemu svn inclusion?

Martin

Re: [Qemu-devel] linux-user/arm unsupported syscalls

[Riku Voipio]

On Wed, Jan 28, 2009 at 05:36:04PM +0100, Martin Mohring wrote:
> Cool. What do you suggest? I could build a new qemu snapshot with that
> fixed. Will you consider this for qemu svn inclusion?

It's not a qemu bug[1], it's a libattr bug. The correct path is to fix
attr (either by that patch or pulling from debian) and recompiling
libacl on top of that. The maemo-sdk qemu [1] has a hack for this, but
fixing this in qemu is wrong since the attr library will fail to
run on real arm kernels.

Cheers,
Riku

[1] http://maemo-sdk.garage.maemo.org/download/host/pool/debian-lenny/free/source/qemu_0.9.1-9maemo1.tar.gz

-- 
"rm -rf" only sounds scary if you don't have backups