This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] mips/o32: fix internal_syscall5/6/7
On 2017-08-15 19:51, Joseph Myers wrote:
> On Tue, 15 Aug 2017, Aurelien Jarno wrote:
>
> > That's one way to do that, however it does seem correct to me that there
> > is no way to force the stack pointer to be valid in an asm code. The
> > stack pointer is used in other asm codes in the glibc, so we need a more
> > global solution.
>
> What's the basis for saying the stack pointer is invalid (as opposed to
> unwind information referring to the original stack pointer, so being
> invalid at the point of the syscall, causing unwinding to crash)? The
1) Looking at the assembly code, the value of the stack pointer around
the syscall depends on the number of time the loop is executed.
2) The crash happens when reaching the stack guard, with a very simple
test case not using recursive functions.
> stack pointer should be unconditionally valid for all asms, on all
> architectures; after all, it's certainly OK to make a function call from
> inside an asm, or for a signal handler (without sigaltstack) to interrupt
> an asm.
>
> I don't think modifying the stack pointer inside an asm can ever be safe
> *in glibc's context* because unwind info might refer to it (even if
> there's a frame pointer), and I don't think making an asm clobber the
> stack pointer is safe either.
That's indeed correct, so in that specific case it indeed make sense
to use an out of line symbol call. I am still worried about other use of
$sp in other asm code.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net