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