[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
Re: [Qemu-devel] [PATCH 4/6] linux-user: Provide safe_syscall for aarch64
Mon, 13 Jun 2016 15:21:14 -0700
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
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.
(The 'as' manual doesn't document what setting .type does in much
It sets the Elf_Sym.st_type field.
But what that implies is very host specific.
doesn't mention a syscall argument in x7, just x0..x5.
I took glibc as definitive, since that's code that definitely works.
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.
Re: [Qemu-devel] [PATCH 0/6] linux-user: safe_syscall updates, Peter Maydell, 2016/06/13
- [Qemu-devel] [PATCH 6/6] linux-user: Provide safe_syscall for ppc64, (continued)