breakpoint.c patch

Todd Whitesel toddpw@wrs.com
Fri Aug 27 16:46:00 GMT 1999


> Part of the uglyness of breakpoint handling seems is that break and
> step return values are overloaded on signals.  Granted that is just
> the way things are implemented on UNIX systems.  I'm thinking it may
> make sense for GDB to have a higher level representation and require
> that the low-level native and remote backends contain whatever cruft
> necessary to distingush between signals, breakpoints, and single step.
> Perhaps something like TARGET_WAITKIND_BREAK and TARGET_WAITKIND_STEP.

Yet more old geezer tales from my days at Green Hills: it was widely felt
that we had to do this, but when somebody finally stepped up to the plate
to do it, his code got backed out as part of a global panic response to a
critical MULTI engineer quitting. Years later they finally got around to
thinking about putting it back in, but I had quit by then.

I suspect that a lot of the hairier algorithms in wait_for_inferior and
friends result from the need to disambiguate things when you crunch
through signals. It's not clear if this can all be pushed down into the
back ends, or if there needs to be some comparing of notes between the
generic code and the back ends. The best way to find out is to try it.
It's got to be better than the current freak of evolution that we have now.

-- 
Todd Whitesel
toddpw @ wrs.com


More information about the Gdb mailing list