This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: break of close loop
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'Daniel Jacobowitz'" <drow at false dot org>,"'Simon Richter'" <Simon dot Richter at hogyros dot de>
- Cc: "'Efim Monjak'" <ymonyak at lipowsky dot de>,<gdb at sources dot redhat dot com>
- Date: Fri, 4 Nov 2005 15:46:29 -0000
- Subject: RE: break of close loop
'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....