This is the mail archive of the gdb-patches@sources.redhat.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]
Other format: [Raw text]

Re: [RFC] breakpoint.c: Don't let adjust_breakpoint_address()adjust watchpoints


On Mon, 15 Mar 2004 23:05:13 +0200
"Eli Zaretskii" <eliz@elta.co.il> wrote:

> > Date: Mon, 15 Mar 2004 13:30:02 -0700
> > From: Kevin Buettner <kevinb@redhat.com>
> > 
> > In the course of running the GDB testsuite on FR-V, I discovered that it's
> > a bad idea to adjust watchpoint addresses.  If any adjustment is done, the
> > watchpoint ends up at the wrong address.  The patch below simply disables
> > adjustment for watchpoints and some eventpoints.
> 
> I'd like to hear more details.  When do we need to adjust the
> breakpoint address, for starters?

We have some documentation about this in gdbint.texinfo:

    The FR-V target (see @file{frv-tdep.c}) requires this method.
    The FR-V is a VLIW architecture in which a number of RISC-like
    instructions are grouped (packed) together into an aggregate
    instruction or instruction bundle.  When the processor executes
    one of these bundles, the component instructions are executed
    in parallel.

    In the course of optimization, the compiler may group instructions
    from distinct source statements into the same bundle.  The line number
    information associated with one of the latter statements will likely
    refer to some instruction other than the first one in the bundle.  So,
    if the user attempts to place a breakpoint on one of these latter
    statements, @value{GDBN} must be careful to @emph{not} place the break
    instruction on any instruction other than the first one in the bundle.
    (Remember though that the instructions within a bundle execute
    in parallel, so the @emph{first} instruction is the instruction
    at the lowest address and has nothing to do with execution order.)

    The FR-V's @code{ADJUST_BREAKPOINT_ADDRESS} method will adjust a
    breakpoint's address by scanning backwards for the beginning of
    the bundle, returning the address of the bundle.

So, on FR-V, we were scanning backwards from the position of a
watchpoint, looking for the start of a VLIW instruction.  Given that
watchpoints are usually set on data, this makes very little sense. 
Even when it might (sort of) make sense, we don't want to do any
adjustment.  E.g, if we were watching a specific executable location -
perhaps it was being mysteriously modified - we wouldn't want to
adjust the location of the watchpoint.  The reason is that we're
viewing that executable location as data.  We want to be informed
when that location changes, not some location (which represents the
start of the VLIW location) before it.

To make this more concise, it makes sense to adjust breakpoint
addresses, because the architectural constraint is related to the
placment of breakpoints in executable code.  It doesn't make sense to
do this kind of adjustment on watchpoints since watchpoints are
concerned with data related accesses.

The other client of TARGET_ADJUST_BREAKPOINT is PPC.  It uses the
breakpoint adjustment mechanism to dereference function descriptors.
I think my proposed change makes sense for this case as well.  I.e,
we don't want to prevent the user from putting a watchpoint on a
function descriptor.  As things stand now, that is what would happen.

Kevin


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