Re: [RFC] Non-executable stack on SPARC

Mark Kettenis
2004-02-01T17:48:29Z

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