Re: break of close loop

Re: break of close loop

[Efim Monjak]

Hi,

as I see the step for debugger is not the same as stepi.
After step command debugger try to go to the next source line.
I think it checks for number of source line.
I mean many single steps can be done before an another source
line is recognised. Recognising of an other source line is need
to complete the step command.
After single step command only one single step is done. I don't know
if for an other address is checked or single step responce is enougth
to complete the single step.

The stub recognise the single step complete if the address is changed.
In this case it is not occurs because jump to the same address.
Yes it is possible break a wait by timeout, but it is not really need.
For user is OK if it can stop execution of such loop by ctrl+c

I fixed this by responce Interrupt Signal if Ctrl+c is received.

It seems the debugger don't recognise if it sends ctrl+c and check
only for responce signal. The SIGTRAP after ctrl+c is recognised
as single step is complete but step exeqution will not be stopped.

Re: break of close loop

[Daniel Jacobowitz]

On Fri, Nov 04, 2005 at 10:14:31AM +0100, Efim Monjak wrote:
> Hi,
> 
> as I see the step for debugger is not the same as stepi.
> After step command debugger try to go to the next source line.
> I think it checks for number of source line.
> I mean many single steps can be done before an another source
> line is recognised. Recognising of an other source line is need
> to complete the step command.
> After single step command only one single step is done. I don't know
> if for an other address is checked or single step responce is enougth
> to complete the single step.

Then your stub is simply wrong.  GDB expects a single step instruction
to execute a single instruction, not until the address changes.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

RE: break of close loop

[Dave Korn]

Daniel Jacobowitz wrote:
> On Fri, Nov 04, 2005 at 10:14:31AM +0100, Efim Monjak wrote:
>> Hi,
>> 
>> as I see the step for debugger is not the same as stepi.
>> After step command debugger try to go to the next source line.
>> I think it checks for number of source line.
>> I mean many single steps can be done before an another source
>> line is recognised. Recognising of an other source line is need
>> to complete the step command.
>> After single step command only one single step is done. I don't know
>> if for an other address is checked or single step responce is enougth
>> to complete the single step.
> 
> Then your stub is simply wrong.  GDB expects a single step instruction
> to execute a single instruction, not until the address changes.


  The stub is probably implemented by placing a temp breakpoint immediately
after the instruction to be tested, but has negelected the fact that to handle
jumps you may need to place the temp breakpoint somewhere _other_ than
immediately after the instruction, and that with conditional branches you need
to place _two_ temp breakpoints, one at the branch target and one immediately
after the branch to catch the fallthrough if the branch is not taken.

  Which is why it's often easier for a stub to just emulate jump/branch insns.



    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: break of close loop

[Simon Richter]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

Hi,

Dave Korn wrote:

>   The stub is probably implemented by placing a temp breakpoint immediately
> after the instruction to be tested, but has negelected the fact that to handle
> jumps you may need to place the temp breakpoint somewhere _other_ than
> immediately after the instruction,

The question at hand appears to be breakpoints placed on top of the 
instruction being stepped, as the instruction steps back to itself. This 
is especially common on architectures with a dedicated "decrement and 
jump if not zero" instruction.

    Simon

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]

RE: break of close loop

[Dave Korn]

Simon Richter wrote:
> Hi,
> 
> Dave Korn wrote:
> 
>>   The stub is probably implemented by placing a temp breakpoint
>> immediately after the instruction to be tested, but has negelected the
>> fact that to handle jumps you may need to place the temp breakpoint
>> somewhere _other_ than immediately after the instruction,
> 
> The question at hand appears to be breakpoints placed on top of the
> instruction being stepped, as the instruction steps back to itself. This
> is especially common on architectures with a dedicated "decrement and
> jump if not zero" instruction.

  That's one of the corner-cases and is indeed one of the reasons why
emulating a branch instruction is often a better idea than trying to let it
run and trap it....


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: break of close loop

['Daniel Jacobowitz']

On Fri, Nov 04, 2005 at 04:18:57PM +0100, Simon Richter wrote:
> Hi,
> 
> Dave Korn wrote:
> 
> >  The stub is probably implemented by placing a temp breakpoint immediately
> >after the instruction to be tested, but has negelected the fact that to 
> >handle
> >jumps you may need to place the temp breakpoint somewhere _other_ than
> >immediately after the instruction,
> 
> The question at hand appears to be breakpoints placed on top of the 
> instruction being stepped, as the instruction steps back to itself. This 
> is especially common on architectures with a dedicated "decrement and 
> jump if not zero" instruction.

If you have such instructions, and you don't have hardware single step,
then you need to be prepared to either wait for the instruction to
finish or else interrupt it.  I don't see the problem.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

RE: break of close loop

[Dave Korn]

'Daniel Jacobowitz' wrote:
> On Fri, Nov 04, 2005 at 04:18:57PM +0100, Simon Richter wrote:
>> Hi,
>> 
>> Dave Korn wrote:
>> 
>>>  The stub is probably implemented by placing a temp breakpoint
>>> immediately after the instruction to be tested, but has negelected the
>>> fact that to handle jumps you may need to place the temp breakpoint
>>> somewhere _other_ than immediately after the instruction,
>> 
>> The question at hand appears to be breakpoints placed on top of the
>> instruction being stepped, as the instruction steps back to itself. This
>> is especially common on architectures with a dedicated "decrement and
>> jump if not zero" instruction.
> 
> If you have such instructions, and you don't have hardware single step,
> then you need to be prepared to either wait for the instruction to
> finish or else interrupt it.  I don't see the problem.

  No, I still think that's a buggy stub; I think that, given a djnz-style
instruction, "stepi" should execute it precisely once (decrement the counter,
keep PC the same if non-zero or advanced to next instruction if counter reg
now == 0), and "nexti" should run it to completion, shouldn't they?  That's
certainly how x86 debugging works natively.  The lack of hardware single-step
is something the stub should transparently handle.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: break of close loop

['Daniel Jacobowitz']

On Fri, Nov 04, 2005 at 03:46:29PM -0000, Dave Korn wrote:
> 'Daniel Jacobowitz' wrote:
> > On Fri, Nov 04, 2005 at 04:18:57PM +0100, Simon Richter wrote:
> >> Hi,
> >> 
> >> Dave Korn wrote:
> >> 
> >>>  The stub is probably implemented by placing a temp breakpoint
> >>> immediately after the instruction to be tested, but has negelected the
> >>> fact that to handle jumps you may need to place the temp breakpoint
> >>> somewhere _other_ than immediately after the instruction,
> >> 
> >> The question at hand appears to be breakpoints placed on top of the
> >> instruction being stepped, as the instruction steps back to itself. This
> >> is especially common on architectures with a dedicated "decrement and
> >> jump if not zero" instruction.
> > 
> > If you have such instructions, and you don't have hardware single step,
> > then you need to be prepared to either wait for the instruction to
> > finish or else interrupt it.  I don't see the problem.
> 
>   No, I still think that's a buggy stub; I think that, given a djnz-style
> instruction, "stepi" should execute it precisely once (decrement the counter,
> keep PC the same if non-zero or advanced to next instruction if counter reg
> now == 0), and "nexti" should run it to completion, shouldn't they?  That's
> certainly how x86 debugging works natively.  The lack of hardware single-step
> is something the stub should transparently handle.

If you feel like defining it as buggy, go ahead.  In practice it may
not be practical to do this - there's a difference between buggy and
sub-ideal.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: break of close loop

[Daniel Jacobowitz]

On Wed, Nov 02, 2005 at 05:41:02PM +0100, Efim Monjak wrote:
> Hi all,
> 
> if it is need to stop in the small loop i.e.:
> for(;;)
>  ;
> which is compiled as one opcode:
> lable:
>  jmp lable:
> 
> GDB works fine by "continue" and "stepi" commands: it sends ctrl+c
> receive the break address and doing no more, but by "step" command
> it try to do a one step after break address is received. The break address
> is the "lable" address and this step starts the loop another time.
> 
> Hier is the part of protocol
> (gdb) c
> Continuing.
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> main () at ../src/main.c:95
> 95                      ;
> (gdb) c
> Continuing.
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> main () at ../src/main.c:95
> 95                      ;
> (gdb) set debug remote 1
> (gdb) stepi
> Sending packet: $s#73...Ack
> remote_interrupt called
> remote_stop called

Why is the step packet not single-stepping the target?  Why do you need
to use C-c to stop the target?  This is a problem with your stub.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

break of close loop

[Efim Monjak]

Hi all,

if it is need to stop in the small loop i.e.:
for(;;)
  ;
which is compiled as one opcode:
lable:
  jmp lable:

GDB works fine by "continue" and "stepi" commands: it sends ctrl+c
receive the break address and doing no more, but by "step" command
it try to do a one step after break address is received. The break address
is the "lable" address and this step starts the loop another time.

Hier is the part of protocol
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
main () at ../src/main.c:95
95                      ;
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
main () at ../src/main.c:95
95                      ;
(gdb) set debug remote 1
(gdb) stepi
Sending packet: $s#73...Ack
remote_interrupt called
remote_stop called
Packet received: T050B:EC3D0040;0D:E03D0040;0F:D8070040;
Sending packet: $m400007d8,4#94...Ack
Packet received: FEFFFFEA
Sending packet: $m40003de8,4#c5...Ack
Packet received: FEFFFFEA
Sending packet: $meafffffe,4#f6...Ack
Packet received: E01
Sending packet: $m40003de4,4#c1...Ack
Packet received: F03D0040
95                      ;
(gdb) stepi
Sending packet: $s#73...Ack
remote_interrupt called
remote_stop called
Packet received: T050B:EC3D0040;0D:E03D0040;0F:D8070040;
Sending packet: $m400007d8,4#94...Ack
Packet received: FEFFFFEA
Sending packet: $m40003de8,4#c5...Ack
Packet received: FEFFFFEA
Sending packet: $meafffffe,4#f6...Ack
Packet received: E01
Sending packet: $m40003de4,4#c1...Ack
Packet received: F03D0040
95                      ;
(gdb) step
Sending packet: $s#73...Ack
remote_interrupt called
remote_stop called
Packet received: T050B:EC3D0040;0D:E03D0040;0F:D8070040;

[hier loop is stopped]

Sending packet: $s#73...Ack

[hier loop is started by last step]

thanks