[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 4/6] linux-user: Provide safe_syscall for aarch6

From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 4/6] linux-user: Provide safe_syscall for aarch64
Date: Mon, 13 Jun 2016 23:28:14 +0100

On 13 June 2016 at 23:21, Richard Henderson <address@hidden> wrote:
> On 06/13/2016 03:04 PM, Peter Maydell wrote:
>>> +        .global safe_syscall_base
>>> +        .global safe_syscall_start
>>> +        .global safe_syscall_end
>>> +        .type   safe_syscall_base, #function
>>> +        .type   safe_syscall_start, #function
>>> +        .type   safe_syscall_end, #function
>> _start and _end aren't function entry points, so is it OK
>> to mark them as functions?
> Yes.  Indeed, if you don't, the objdump will think these are data symbols
> and fail to disassemble the instructions that follow.

I was told this was an objdump bug... it certainly
seems like an objdump bug to me, because this works
on the other architectures.

>> (The 'as' manual doesn't document what setting .type does in much
>> detail...)
> It sets the Elf_Sym.st_type field.
> But what that implies is very host specific.
>> http://man7.org/linux/man-pages/man2/syscall.2.html
>> doesn't mention a syscall argument in x7, just x0..x5.
> I took glibc as definitive, since that's code that definitely works.

If we never use the 7th syscall argument (and we can't,
since it doesn't exist on some hosts), then it's
unnecessary work, though I guess coming back to fix
all these host functions later might be tedious.

> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/aarch64/syscall.S;h=98c1b42ee96fe0fb39955849773ca16d095803e0;hb=HEAD
> I'll also point you at the kernel's __sys_trace, which does in fact save and
> restore all 8 registers around the tracing call-outs.
>>> +       mov     x9, x0          /* signal_pending pointer */
>>> +       mov     w8, w1          /* syscall number */
>> Seems a bit odd to use a 32-bit move for this when our input
>> calling convention has it as 64 bits and the kernel's calling
>> convention has it as 64 bits.
> I got that from glibc too.

glibc's syscall() takes the system parameter as an int and
does a sign-extending move into x0 with an uxtw.
safe_syscall() takes a long, so it's already 64 bits.

-- PMM

reply via email to

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