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 20:21, Joseph Myers wrote:
> 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.
Oh didn't thought about that, thanks for the explanation.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net