RE: FW: bug ????

RE: FW: bug ????

[Newman, Mark (N-Superior Technical Resource Inc)]

I have no problem with either way.  My role was not of much significance
in this patch.

I have not received any assignment paperwork.

                                        Mark  

-----Original Message-----
From: Andrew Cagney [mailto:ac131313@redhat.com]
Sent: Thursday, August 21, 2003 11:28 AM
To: Michael Snyder
Cc: Newman, Mark (N-Superior Technical Resource Inc);
gdb-patches@sources.redhat.com
Subject: Re: FW: bug ????


> 2003-08-15  Mark Newman  <mark.newman@lmco.com>
> 
>        * tracepoint.c (trace_dump_command): Trace break address
>        is subject to DECR_PC_AFTER_BREAK.

Michael,

I'd use a change log like:

	YYYY-MM-DD Michael Snyder ...

		* tracepoint.c (..): ...
		Problem reported by Mark Newman.

so that it more exactly reflects the fact that you, and not Mark, made 
the change (while still giving due credit) (this makes auditing much 
much easier).

I've sent Mark the relevant paper work for an assignment (but that isn't

needed here).

Andrew

FW: bug ????

[Newman, Mark (N-Superior Technical Resource Inc)]

-----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

Re: FW: bug ????

[Michael Snyder]

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)
      {

Re: FW: bug ????

[Andrew Cagney]

> 2003-08-15  Mark Newman  <mark.newman@lmco.com>
> 
>        * tracepoint.c (trace_dump_command): Trace break address
>        is subject to DECR_PC_AFTER_BREAK.

Michael,

I'd use a change log like:

	YYYY-MM-DD Michael Snyder ...

		* tracepoint.c (..): ...
		Problem reported by Mark Newman.

so that it more exactly reflects the fact that you, and not Mark, made 
the change (while still giving due credit) (this makes auditing much 
much easier).

I've sent Mark the relevant paper work for an assignment (but that isn't 
needed here).

Andrew

Re: FW: bug ????

[Michael Snyder]

Andrew Cagney wrote:
>> 2003-08-15  Mark Newman  <mark.newman@lmco.com>
>>
>>        * tracepoint.c (trace_dump_command): Trace break address
>>        is subject to DECR_PC_AFTER_BREAK.
> 
> 
> Michael,
> 
> I'd use a change log like:
> 
>     YYYY-MM-DD Michael Snyder ...
> 
>         * tracepoint.c (..): ...
>         Problem reported by Mark Newman.
> 
> so that it more exactly reflects the fact that you, and not Mark, made 
> the change (while still giving due credit) (this makes auditing much 
> much easier).

So changed and committed.