[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] qemu ARM: Unsupported syscall: 983040

From: Peter Maydell
Subject: Re: [Qemu-discuss] qemu ARM: Unsupported syscall: 983040
Date: Thu, 29 Jan 2015 13:15:04 +0000

On 29 January 2015 at 12:36, eth0 <address@hidden> wrote:
> I'm trying to run a ARM32 binary within qemu but I get seg fault:
> address@hidden:~/squashfs-root# chroot . ./qemu-arm bin/xxx
> qemu: Unsupported syscall: 983040
> qemu: Unsupported syscall: 983040
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> Segmentation fault
> address@hidden:~/squashfs-root# file bin/xxx
> bin/xxx: ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses
> shared libs), stripped
> How would I diagnose this further? Is this a bug in qemu? I'm not sure what
> syscall 983040 is and I can't seem to find any documentation on it.

983040 is 0xF0000 hex. The kernel defines syscall numbers here:

0xf0000 is in the "ARM private region":

#define __ARM_NR_BASE (__NR_SYSCALL_BASE+0x0f0000)
#define __ARM_NR_breakpoint (__ARM_NR_BASE+1)
#define __ARM_NR_cacheflush (__ARM_NR_BASE+2)
#define __ARM_NR_usr26 (__ARM_NR_BASE+3)
#define __ARM_NR_usr32 (__ARM_NR_BASE+4)
#define __ARM_NR_set_tls (__ARM_NR_BASE+5)

and you can see that there's no defined syscall name for
__ARM_NR_BASE+0, which suggests your binary is doing something
wrong. (There is actually defined kernel behaviour for 0xf0000:
the arm_syscall() function in the kernel does this:

        case 0: /* branch through 0 */
                info.si_signo = SIGSEGV;
                info.si_errno = 0;
                info.si_code  = SEGV_MAPERR;
                info.si_addr  = NULL;

                arm_notify_die("branch through zero", regs, &info, 0, 0);
                return 0;

...but the defined behaviour is "send the program a SIGSEGV",
so it seems unlikely your binary is really relying on it.)

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]