This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] mips/o32: fix internal_syscall5/6/7

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

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]