Re: questions on struct sigcontext

[Ralf Baechle <ralf@linux-mips.org>]

On Wed, Dec 12, 2007 at 11:44:14AM -0600, Chris Friesen wrote:

> First, I'm not subscribed to the list so I'd appreciate being cc'd on any 
> replies.
>
> We have a project getting started with MIPS, and one of the things that 
> we're trying to bring in is some exception-handling code that logs various 
> information about the ways that apps fail.
>
> In particular, the guys working on this have asked for the STATUS, CAUSE, 
> BADVADDR, and FPC_EIR registers to be made available as part of struct 
> sigcontext so that they can determine exactly why the app is failing.

The status register doesn't provide useful information about application
problems since it almost exclusivly affects kernel level operation.  So
its not exported to userspace.

Cause I agree could occasionally be interesting.  Historically the
Linux/MIPS stackframe is derived from the IRIX stackframe.  But Linux/MIPS
did never populate the sc_cause field - no debugger or anything was using it.
So eventually the field got recycled for the DSP ASE.  The hard part here
is finding place in the stackframe without breaking compatibility - and
there are other users competing ...

C0_badvaddr is available in the si_addr field of struct siginfo.

The FIR register is the "FP Implementation and Revision register" which is
read-only so the same for all processes. A debugger can access it at any
time and there is no need to waste space in the stack frame on it.

> Looking at include/asm-mips/sigcontext.h I can see that these registers 
> appear to be in the struct, but are either marked as "unused" or now have 
> different names.
>
> Am I correct that these registers are not currently exported to userspace 
> on a fault?  If this is the case, why not?  Does anyone have a patch to 
> enable this export?

Be very, very, very careful if you're changing struct siginfo.  Applications
know about it.  Iow if you change it the wrong way you break binary or
even source compatibility and usually that's in very subtle ways.

(Honestly, I hate our stackframe, especially the 32-bit one which is hell
of overbloated.  I *wish* I could just scrap it but its one of those holy
cows - and I don't feel carnivorous enough yet to butcher it ;-)

  Ralf