This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
- From: Ralf Baechle <ralf at linux-mips dot org>
- To: Andrew Haley <aph-gcc at littlepinkcloud dot COM>
- Cc: David Daney <ddaney at avtrex dot com>, linux-mips at linux-mips dot org, Richard Sandiford <rsandifo at nildram dot co dot uk>, gcc at gcc dot gnu dot org
- Date: Tue, 13 Nov 2007 12:10:36 +0000
- Subject: Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
- References: <473957B6.3030202@avtrex.com> <18233.36645.232058.964652@zebedee.pink>
On Tue, Nov 13, 2007 at 11:48:53AM +0000, Andrew Haley wrote:
> David Daney writes:
> > With the current kernel (2.6.23.1) in my R5000 based O2 it seems
> > impossible for GCC's exception unwinding machinery to unwind through
> > signal frames. The cause of the problems is the
> > ICACHE_REFILLS_WORKAROUND_WAR which puts the sigcontext at an almost
> > impossible to determine offset from the signal return trampoline. The
> > unwinder depends on being able to find the sigcontext given a known
> > location of the trampoline.
> >
> > It seems there are a couple of possible solutions:
> >
> > 1) The comments in war.h indicate the problem only exists in R7000
> > and E9000 processors. We could turn off the workaround if the
> > kernel is configured for R5000. That would help me, but not those
> > with the effected systems.
> >
> > 2) In the non-workaround case, the siginfo immediately follows the
> > trampoline and the first member is the signal number. For the
> > workaround case the first word following the trampoline is zero.
> > We could replace this with the offset to the sigcontext which is
> > always a small negative value. The unwinder could then distinguish
> > the two cases (signal numbers are positive and the offset
> > negative). If we did this, the change would have to be coordinated
> > with GCC's unwinder (in libgcc_s.so.1).
> >
> > Thoughts?
>
> The best solution is to put the unwinder info in the kernel. Does
> MIPS use a vDSO ?
No though we should.
Another reason is to get rid of the classic trampoline the kernel installs
on the stack. On some multiprocessor systems it requires a cacheflush
operation to be performed on all processors which is expensive. Having
the trampoline in a vDSO would solve that.
I need to look into it, not sure what it would take.
Ralf