A patch for ia32 hardware watchpoint.
Todd Whitesel
toddpw@windriver.com
Wed Mar 8 19:44:00 GMT 2000
> 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 numbering scheme I prefer has multiple layers. For each event type
that GDB handles in a generic way, there is a value of TARGET_WAITKIND_*
that is always preferred. For miscellaneous events that GDB doesn't know
how to handle specifically, you have TARGET_WAITKIND_SIGNALLED or
TARGET_WAITKIND_CPU_EXCEPTION, both of which activate a target-defined
auxiliary field that carries the signal/exception type. When this happens:
For unixy targets, you get TARGET_WAITKIND_SIGNALLED and a signal number.
For raw targets, you get TARGET_WAITKIND_CPU_EXCEPTION and a vector number
(or something like it -- on many RISC chips this is not a simple integer).
The reactionary position is:
It is not the job of the generic inferior event stuff to disambiguate
unixy signals like SIGTRAP. That is what unix tdep files are for.
The more reasonable position is:
As early as possible, I want a SIGTRAP to become a TARGET_WAITKIND_BREAKPOINT
so that above some layer I never have to think about SIGTRAP on any target,
except in the case of a spurious SIGTRAP that matches no breakpoint, which
should be treated like any other uncaught signal.
--
Todd Whitesel
toddpw @ windriver.com
More information about the Gdb
mailing list