Re: A patch for ia32 hardware watchpoint.

[Jim Kingdon <kingdon at redhat dot com>]

> Yeah. This is about as bad as crunching target events through unix
> signals, something that only ever made sense on ptrace() targets
> which couldn't do any better. "But the code lives on"

Always amusing to hear people talking about my designs :-) (also see
comment in target.h at enum target_signal).

The deep question is whether you want GDB to canonicalize things.  I
do see some value in getting (for example) a SEGV when you access
memory which is not mapped by the MMU (if you have one) across all
targets.  Both for users and for scripts.

If you answer pro-canonical, then the right solution is to add
additional fields (most native platforms have arch-dependent signal
codes, for example, and GDB could be taught to pass them along or
generate them for stubs and such).  I think that ptrace() targets
could get at the signal codes but not necessarily in a clean way
(wait4 and friends don't seem to return them).

If you answer anti-canonical, then you want functions in the target
vector to do things like report stop status to the user.

The two approaches aren't mutually exclusive, actually, we probably
want both a canonicalized status and a way to get more specific
information in a free-form way.

The situation might be analogous for errno, although errno is such a
poor fit for things which happen to targets (e.g. "address out of
range" maps to EIO.  Bletch), that I kind of doubt it is worth the
bother to do the canonicalization thing.  Unless perhaps if we wanted
to come up with a GDB-specific canonical set of errors.