questions on struct sigcontext
Hi all,
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.
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?
It seems odd that mips app designers wouldn't want this information to be made available.
Any information you can provide would be useful.
Chris
Quoted 5 lines · Chris Friesen
Hi all,
First, I'm not subscribed to the list so I'd appreciate being cc'd on any replies.
Quoted 7 lines
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_EIRregisters to be made available as part of struct sigcontext so that they can determine exactly why the app is failing.Looking at
include/asm-mips/sigcontext.hI 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?
No.
Most of the information is available. The si_addr and si_code of the sigcontext are populated as well as the ucontext at the fault.
Given all this and the code at $pc when the fault occurred, it is a simple matter to determine what happened.
I have seen some kernels patched so that an OOPS type dump was created in the trap handler, but this doesn't really add anything to the information that is already available in user space.
David Daney
Quoted 1 line · David Daney
Most of the information is available. The
si_addrandsi_codeof the sigcontext are populated as well as the ucontext at the fault.
I assume this should be siginfo rather than sigcontext?
Quoted 1 line
Given all this and the code at $pc when the fault occurred, it is a simple matter to determine what happened.
Okay. I'll pass that information on and see if it's sufficient.
Thanks,
Chris
Quoted 5 lines · Chris Friesen
Quoted 1 line · David Daney
Most of the information is available. The
si_addrandsi_codeof the sigcontext are populated as well as the ucontext at the fault.I assume this should be siginfo rather than sigcontext?
Yes. In the three parameter form of the signal handler the second and third parameters are pointers to the siginfo and ucontext.
Quoted 8 lines
Quoted 2 lines
Given all this and the code at $pc when the fault occurred, it is a simple matter to determine what happened.
Okay. I'll pass that information on and see if it's sufficient.
Thanks,
Chris
Quoted 10 lines · Chris Friesen
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_EIRregisters 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.
Quoted 7 lines
Looking at
include/asm-mips/sigcontext.hI 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
Quoted 14 lines · Chris Friesen
Hi all,
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_EIRregisters to be made available as part of struct sigcontext so that they can determine exactly why the app is failing.
Quoted 7 lines
Looking at
include/asm-mips/sigcontext.hI 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?
There used to be slots for badvaddr and cause. You'll have to ask Ralf why he decided to clobber them for DSP state, I don't remember :-) I suspect they may never have held useful information for you; we don't context switch them for userspace, so an intervening fault in kernel space or in another thread could change them.
FPC_EIR is, unless I misremember, constant and read only. You can just read it.
Signature · 2 lines
Daniel Jacobowitz CodeSourcery
Quoted 5 lines · Daniel Jacobowitz
There used to be slots for badvaddr and cause. You'll have to ask Ralf why he decided to clobber them for DSP state, I don't remember :-) I suspect they may never have held useful information for you; we don't context switch them for userspace, so an intervening fault in kernel space or in another thread could change them.
Correct, we never filled badvaddr and cause, so it was easy to recycle those fields.
Ralf
Quoted 5 lines · Daniel Jacobowitz
There used to be slots for badvaddr and cause. You'll have to ask Ralf why he decided to clobber them for DSP state, I don't remember :-) I suspect they may never have held useful information for you; we don't context switch them for userspace, so an intervening fault in kernel space or in another thread could change them.
I'm a bit confused as to how they would never have held useful information--did you mean the registers themselves, or the entries in struct sigcontext?
If the cause/badvaddr entries in struct sigcontext were filled in by the exception handler in the kernel, wouldn't the values in that struct be completely valid even if the registers themselves were changed before userspace could handle the signal?
If this is not the case then it seems like si_addr/si_code wouldn't be trustworthy either.
Chris
Quoted 9 lines · Chris Friesen
Quoted 5 lines · Daniel Jacobowitz
There used to be slots for badvaddr and cause. You'll have to ask Ralf why he decided to clobber them for DSP state, I don't remember :-) I suspect they may never have held useful information for you; we don't context switch them for userspace, so an intervening fault in kernel space or in another thread could change them.
I'm a bit confused as to how they would never have held useful information--did you mean the registers themselves, or the entries in struct sigcontext?
The entries in the sigcontext. As Ralf said, they never held valid values.
Quoted 2 lines
If the cause/badvaddr entries in struct sigcontext were filled in by the exception handler in the kernel,
It would appear that they are not.
Quoted 3 lines
wouldn't the values in that struct be completely valid even if the registers themselves were changed before userspace could handle the signal?
If this is not the case then it seems like si_addr/si_code wouldn't be trustworthy either.
This I am not sure about :(, However knowing the values of all registers (and perhaps /proc/self/maps) and $pc you can easily derive what happened.
David Daney
Quoted 4 lines · Chris Friesen
If the cause/badvaddr entries in struct sigcontext were filled in by the exception handler in the kernel, wouldn't the values in that struct be completely valid even if the registers themselves were changed before userspace could handle the signal?
Yeah, my reply didn't make much sense. Trust Ralf's instead.
Signature · 2 lines
Daniel Jacobowitz CodeSourcery