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

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 15 Aug 2017, Aurelien Jarno wrote:

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

What that says to me is that the alloca (to ensure frame pointer creation) 
is fundamentally problematic if the syscall macro can be used many times 
in a loop within a function, because it will allocate unbounded amounts of 
stack.

In which case having a volatile integer variable with value 4, declaring a 
VLA whose size is that variable, and storing a pointer to that VLA in a 
variable, would be an alternative to alloca to force a frame pointer, but 
with deallocation happening when the scope ends rather than the function 
ending (and the syscall macro has its own scope, so using it inside a loop 
wouldn't be a problem).

-- 
Joseph S. Myers
joseph@codesourcery.com