questions on struct sigcontext

questions on struct sigcontext

[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_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

Re: questions on struct sigcontext

[David Daney]

Chris Friesen wrote:
> 
> 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?

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

Re: questions on struct sigcontext

[Chris Friesen]

David Daney wrote:

> 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.

I assume this should be siginfo rather than sigcontext?

> 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

Re: questions on struct sigcontext

[David Daney]

Chris Friesen wrote:
> David Daney wrote:
> 
>> 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.
> 
> 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.

> 
>> 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

Re: questions on struct sigcontext

[Ralf Baechle]

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

Re: questions on struct sigcontext

[Daniel Jacobowitz]

On Wed, Dec 12, 2007 at 11:44:14AM -0600, Chris Friesen wrote:
>
> 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?

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.

-- 
Daniel Jacobowitz
CodeSourcery

Re: questions on struct sigcontext

[Ralf Baechle]

On Wed, Dec 12, 2007 at 02:00:32PM -0500, Daniel Jacobowitz wrote:

> 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

Re: questions on struct sigcontext

[Chris Friesen]

Daniel Jacobowitz wrote:

> 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

Re: questions on struct sigcontext

[David Daney]

Chris Friesen wrote:
> Daniel Jacobowitz wrote:
> 
>> 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.

> 
> 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.

> 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

Re: questions on struct sigcontext

[Daniel Jacobowitz]

On Wed, Dec 12, 2007 at 05:47:51PM -0600, Chris Friesen wrote:
> 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.

-- 
Daniel Jacobowitz
CodeSourcery