linux-mips
[Top] [All Lists]

Re: questions on struct sigcontext

To: Chris Friesen <cfriesen@nortel.com>
Subject: Re: questions on struct sigcontext
From: David Daney <ddaney@avtrex.com>
Date: Wed, 12 Dec 2007 16:06:13 -0800
Cc: Daniel Jacobowitz <dan@debian.org>, linux-mips@linux-mips.org, ralf@linux-mips.org
In-reply-to: <47607327.5090709@nortel.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <47601DEE.4090200@nortel.com> <20071212190032.GA30506@caradoc.them.org> <47607327.5090709@nortel.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Thunderbird 1.5.0.12 (X11/20071019)
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

<Prev in Thread] Current Thread [Next in Thread>