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

[Richard Henderson]

On 06/13/2016 03:28 PM, Peter Maydell wrote:
> 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.
> https://bugs.linaro.org/show_bug.cgi?id=815

This may be a hold-over from arm32, which as you recall has a rather 
complicated scheme for annotating data vs instructions.

> > 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.

You're probably right about the 7th syscall argument on a 64-bit host.

> 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.

Well, uxtw is a zero-extending move.  So...


r~