Re: [RFC] Non-executable stack on SPARC

[Mark Kettenis <kettenis at chello dot nl>]

   Date: 27 Jan 2004 09:56:52 +0200
   From: Eli Zaretskii <eliz@elta.co.il>

   > Date: Mon, 26 Jan 2004 13:42:30 +0100 (CET)
   > From: Mark Kettenis <kettenis@chello.nl>
   > 
   > With my patch,
   > or with the suggestions I made below, GDB will usually still see
   > SIGSEG under normal circumstances.  GDB will only convert such a
   > signal into SIGTRAP if there's a breakpoint inserted at the point
   > where the inferior stopped.

   Where is this last condition tested to be true?  The if clause where
   you wanted to add SIGSEGV doesn't test that, I think.

It's quite a bit further down where this gets resolved; see
infrun.c:1962.  The signal is only converted into SIGTRAP if the
signal can be explained by a breakpoint.

   > As to punting the SIGSEGV to SIGTRAP conversion to the architecture:
   > we could do this in target_wait() or target_wait_hook(), but that
   > would offload it to the target we're running on and not to the
   > architecture.

   So perhaps we need an architecture way to do such conversions.

   My line of thought is that it's IMHO fundamentally wrong to push
   target- or architecture-specific details into the application level of
   GDB, which is what infrun.c is.  infrun.c should deal with high-level
   logic of handling a stopped inferior, it should not IMHO know about
   intricacies of specific targets.

The question is to what extent this is an intricacy of a specific
target.  All targets that use ON_STACK call dummies and have a
non-executable stack will need this adjustment.  More and more systems
gain non-executable stacks.  Hopefully no other ABI's besides SPARC
will require ON_STACK call dummies, but that's probably wishful
thinking.

Anyway, the SIGSEGV would be handled exactly as we already handle
SIGILL and SIGEMT.  Pushing things off to the target/architecture
vector would involve code duplication that I'd rather avoid.

Mark