Re: [PATCH RFA] TARGET_ADJUST_BREAKPOINT_ADDRESS...

[Kevin Buettner <kevinb at cygnus dot com>]

On Jun 21,  3:05am, Eli Zaretskii wrote:

> > Date: Tue, 20 Jun 2000 20:14:33 -0700
> > From: Kevin Buettner <kevinb@cygnus.com>
> > 
> > If a breakpoint address is adjusted, there's some new code in
> > breakpoint.c which'll print out a warning.  Such a warning might
> > look something like this...
> > 
> > 	(gdb) b foo
> > 	warning: Breakpoint address moved from 0x06200090 to 0x0620008c.
> > 	Breakpoint 1 at 0x0620008c: file bar.c, line 21.
> 
> Printing a message is a good idea, but making it a warning IMHO is
> not.  Warning is for some potential trouble, while in this case GDB is
> doing The Right Thing.  Printing a warning will confuse users.

For the target which caused me to add this code, it seemed like a
warning was appropriate.  It's unfortunate that an NDA prevents me
from discussing the specifics.  However, I think your idea below will
work as well or better for conveying the information to the user.

> Perhaps we should make the information about moving the breakpoint
> part of the "Breakpoint 1 at ..." message.

I think this is a good idea.  Perhaps something like

    Breakpoint 1 at 0x0620008c (moved from 0x6200090): file bar.c, line 21.

or perhaps

    Breakpoint 1 at 0x0620008c (adjusted from 0x6200090): file bar.c, line 21.

To do this, I think it'll be necessary to add a field to the
breakpoint structure which would record the address requested vs. the
address you actually got.

The reason that I like this idea better than the warning that I put
in is that you would also presumably be able to see that the breakpoint
had been moved (adjusted) when doing ``info breakpoints''.  This is
good because you could miss the warning when it's first printed.  (gdb
prints a lot of stuff at you and sometimes we only see what we want
to see.)

OTOH, if an internal breakpoint was adjusted, this mechanism would
not warn you of that fact.  I'm not sure if this is a problem or not.
(I'm also not sure if it can happen or not.)

> My other comment is about hardware-assisted breakpoints: it looks
> like, at least in some of the examples you gave, the address of
> hardware-assisted breakpoints will also need to be adjusted in the
> same way.  So I think we need some provision for that as well.

I don't have a lot of experience with hardware assisted breakpoints. 
Is there something that I forgot do which'll prevent the adjustment
from happening for hardware assisted breakpoints as well?