This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
FW: bug ????
- From: "Newman, Mark (N-Superior Technical Resource Inc)" <mark dot newman at lmco dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Fri, 15 Aug 2003 12:55:50 -0400
- Subject: 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