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]

FW: bug ????



-----Original Message-----
From: Michael Snyder [mailto:msnyder@redhat.com]
Sent: Thursday, August 14, 2003 4:16 PM
To: Newman, Mark (N-Superior Technical Resource Inc)
Subject: Re: bug ????


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?

Cheers,
Michael




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