This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/4] aarch64: Re-implement setcontext without sigreturn syscall
- From: Will Newton <will dot newton at linaro dot org>
- To: Marcus Shawcroft <marcus dot shawcroft at gmail dot com>
- Cc: catalin dot marinas at arm dot com, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 18 Mar 2014 15:35:29 +0000
- Subject: Re: [PATCH 2/4] aarch64: Re-implement setcontext without sigreturn syscall
- Authentication-results: sourceware.org; auth=none
- References: <1394707543-9690-1-git-send-email-will dot newton at linaro dot org> <1394707543-9690-2-git-send-email-will dot newton at linaro dot org> <CAFqB+Px=jBrWTwVg97qGcLbpmnEP5qq5mQKEuDQrBmPO2k_fjw at mail dot gmail dot com>
On 17 March 2014 17:48, Marcus Shawcroft <marcus.shawcroft@gmail.com> wrote:
> On 13 March 2014 10:45, Will Newton <will.newton@linaro.org> wrote:
>
>
>> + /* Restore the general purpose registers. */
>> + mov x0, x9
>
> Looks like this code is treating x9 as callee saved over the kernel
> call. While this is true with the current implementation of the
> kernel, the glibc port for AArch64 currently treats only the argument
> registers as preserved. This is a hang over from the early days of
> the AArch64 port when the kernel guys wanted the glibc port to be
> conservative in this respect in order that they have the opportunity
> to be selective in what was restored on exit from the kernel.
Really, is that true? It seems to me you would have to save/restore in
userland anyway so I am not sure what would actually be saved by
making syscalls behave so differently from function calls.
> Catalin, Can you comment on the above paragraph? Is it still
> important that glibc / user space be conservative in its assumptions
> about which registers are preserved over system call or can we now
> relax this position and exploit the fact that the kernel preserves
> x9-x30 over kernel calls?
>
>
>> + cfi_def_cfa(x0, 0)
>
> Space before (....
Thanks, I fixed that.
--
Will Newton
Toolchain Working Group, Linaro