This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: A patch for ia32 hardware watchpoint.


> I was planning to propose that the breakpoint pointer itself be passed
> to the target_{insert,remove}_{break,watch}point() functions, so this
> is as good of time as any.  

I say Just Do It. I am sitting on some local code here that tracks
breakpoints added to the target by a third party, and I ended up needing
the breakpoint shadow field to be available to those functions.

In my code I have functions called "target_better_{insert,remove}_breakpoint"
which take a struct breakpoint * and a CORE_ADDR although the CORE_ADDR is
only needed in a couple cases that show up in the overlay support (IIRC).
Previous users of the regular target_[a-z]*_breakpoint functions have been
changed to use the new ones, and I hack the target stack interface (don't
ask) in order to get the information down to where I need it. If the real
target interface passed the breakpoint pointer down, presto, no more hack.

As far as I'm concerned, passing the breakpoint pointer is the right way
to go; we should get away from the assumption that a target side breakpoint
is an address with some #define'd size, and push that stuff into a default
implementation that can be invoked easily by people writing new target
support.

> The reason I want this is so that GDB's target code can record target-
> specific info about the breakpoint.  For example, if the target gives
> the break/watchpoint an ID, the insert function can record it in the
> breakpoint so it is available for use in the delete function.  Right
> now, my WDB target code inserts a record into a data structure which
> maps WDB's breakpoint IDs with the thread+address when a breakpoint is 
> inserted.  The remove code searches for any breakpoint that matches the
> thread+address and removes that ID.  

I'm doing much the same (except it's more complicated for historical
reasons) to handle WTX breakpoints.

Actually I ended up having a bunch of functions to search the breakpoint
list for a given ID and {delete,insert,remove} it. Since other host programs
can delete my breakpoints, I had to be able to react appropriately when the
removal message showed up.

> Also, while many target vectors report error reasons through errno, 
> it leaves a bad taste in my mouth.  Perhaps this is because we have
> to map target errors into UNIX/POSIX errnos, and there isn't always
> a clean mapping.

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"

-- 
Todd Whitesel
toddpw @ windriver.com

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]