Re: FW: bug ????

[Michael Snyder <msnyder at redhat dot com>]

Newman, Mark (N-Superior Technical Resource Inc) wrote:

> > Michael -
> >
> > I am not certain how to handle this.  Perhaps you can give me some
> > insight.  I am not familar with GDB internals.
> >
> > I appears that the the following is not working correctly in 
> > trace_dump_command 
> >
> > /* The current frame is a trap frame if the frame PC is equal
> >    to the tracepoint PC.  If not, then the current frame was
> >    collected during single-stepping.  */
> >
> > stepping_frame = (t->address != read_pc ());
> >
> > The trace address is one less than the read_pc address (I am not
> > stepping).  Either gdbserver needs to adjust the register set so that
> > the pc is back by one or some adjustment needs to be made to t->address
> > so it looks at the next address.  Should the tracepoint look at the
> > state prior to executing the instruction at the address or after the
> > instruction is executed? 
> >
> >    
>
> Ah, this is the old DECR_PC_AFTER_BREAK problem.  I never
> ran into it because I never had tracepoints working on an x86 target
> (just about the only one left where it's an issue.
>
> Try this:
>
>    stepping_frame = (t->address != (read_pc () - DECR_PC_AFTER_BREAK);
>
> The macro should evaluate to zero if the pc points to the trap 
> instruction, and
> to (sizeof(trap_instruction) if it points past the trap.
>
> If this works, why don't you submit it as a patch to gdb-patches?

Hi Mark,

Thanks for your two bug reports and fixes.   These are small enough that
we can accept them without an FSF assignment, but if you don't have one
on file and are planning to do more extensive work on gdb, this would be
the time to get the paperwork done.

If you'll have a look at the file gdb/CONTRIBUTE, there's an outline of
what a submission should look like.  I'll give you an example by whipping
this one into shape (see below):  You can consider this one approved.

-------------------------------------------------------------------------------------------------
The bug: tracepoint.c tests a tracepoint location without allowing
for DECR_PC_AFTER_BREAK, therefore the test fails on x86.

2003-08-15  Mark Newman  <mark.newman@lmco.com>

       * tracepoint.c (trace_dump_command): Trace break address
       is subject to DECR_PC_AFTER_BREAK.

*************** trace_dump_command (char *args, int from
*** 2511,2517 ****
      to the tracepoint PC.  If not, then the current frame was
      collected during single-stepping.  */

!   stepping_frame = (t->address != read_pc ());

   for (action = t->actions; action; action = action->next)
     {
--- 2511,2517 ----
      to the tracepoint PC.  If not, then the current frame was
      collected during single-stepping.  */

!   stepping_frame = (t->address != (read_pc () - DECR_PC_AFTER_BREAK));

   for (action = t->actions; action; action = action->next)
     {