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