Re: [RFA 1/2] mips: Switch inferior function calls to ON_STACK method.

["Maciej W. Rozycki" <macro@codesourcery.com>]

On Sat, 5 May 2012, Mark Kettenis wrote:

> >  As per my suggestion I think it makes sense to document any peculiarities 
> > of this specific implementation here as well (in this case the safety to 
> > use with non-executable stack).
> 
> The non-executable stack issue really isn't specific to this
> implementation though.  On OpenBSD the stack is non-executable on all
> architectures where it is possible (including through a clever trick
> on i386).  I haven't tried ON_STACK on all of them, but it works on
> all of them.

 After some thinking I realised that the reliance on signal delivery to 
work properly to trap non-executable stack may actually be a problem for 
bare-iron targets.  I'd expect TLB exceptions not to be forwarded up the 
debug stack in a typical JTAG debugging scenario -- it's not obvious how 
they should be mapped to signals even, the low-level hardware has no way 
to classify them and not all have to be fatal; in about the most 
sophisticated scenario (which is not unlikely, I did that many times 
myself) consider debugging Linux (the kernel) through JTAG.

 Instead you'll have the joy of running or stepping through the exception 
handler (from the probe's point of view it's really no different to an 
ordinary jump; in the hardware stepping mode the processor will just trap 
at the exception handler's entry point instead of the intended breakpoint 
location) on the target and your device being debugged may go astray, e.g. 
panic blinking LEDs or trigger hardware reset.

 Given that this feature in the MIPS case comes from the SmartMIPS ASE 
(that as noted earlier has been designed with smart cards in mind) I think 
such a scenario is actually not unlikely, even though, as I say, I have 
never had an opportunity to deal with a MIPS processor that had this 
non-executable stack feature implemented.

  Maciej