This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA 1/2] mips: Switch inferior function calls to ON_STACK method.
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