Subject: questions on struct sigcontext

From: "Chris Friesen" <[email-masked]>
Date: Wed, 12 Dec 2007 11:44:14 -0600

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

---

From: David Daney <[email-masked]>
Date: Wed, 12 Dec 2007 10:12:01 -0800

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

---

From: "Chris Friesen" <[email-masked]>
Date: Wed, 12 Dec 2007 12:34:19 -0600

> sigcontext are populated as well as the ucontext at the fault.

I assume this should be siginfo rather than sigcontext?

> simple matter to determine what happened.

Okay.  I'll pass that information on and see if it's sufficient.

Thanks,

Chris

---

From: David Daney <[email-masked]>
Date: Wed, 12 Dec 2007 10:44:14 -0800

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

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 12 Dec 2007 18:57:26 +0000

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

> 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

---

From: Daniel Jacobowitz <[email-masked]>
Date: Wed, 12 Dec 2007 14:00:32 -0500

> on a fault?  If this is the case, why not?  Does anyone have a patch to 

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

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 12 Dec 2007 19:04:55 +0000

> 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

---

From: "Chris Friesen" <[email-masked]>
Date: Wed, 12 Dec 2007 17:47:51 -0600

> 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

---

From: David Daney <[email-masked]>
Date: Wed, 12 Dec 2007 16:06:13 -0800

> information--did you mean the registers themselves, or the entries in 

The entries in the sigcontext.  As Ralf said, they never held valid values.

> exception handler in the kernel,

It would appear that they are not.

> wouldn't the values in that struct be 

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

---

From: Daniel Jacobowitz <[email-masked]>
Date: Thu, 13 Dec 2007 10:36:21 -0500

> userspace could handle the signal?

Yeah, my reply didn't make much sense.  Trust Ralf's instead.

-- 
Daniel Jacobowitz
CodeSourcery