This is the mail archive of the gdb@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]

Re: remote debugging packets

Manoj Verma, Noida wrote:

Do you mean to indicate that the debugger may not stop at line #YY in this
case?


Since line xx and yy match to the same pc, only one breakpoint can be set and it would hit only once. It would be equivalent to putting duplicate breakpoints. This is because your architecture seems to have this loop instruction.

cheers
Ramana



-----Original Message-----
From: Mark Salter [mailto:msalter@redhat.com]
Sent: Friday, November 21, 2003 9:37 PM
To: manojv@noida.hcltech.com
Cc: gdb@sources.redhat.com
Subject: Re: remote debugging packets




Manoj Verma, Noida writes:


Let me explain my concern in this way...
I have following C snippet:


...
for(i=0; i<100; i++) // say line #xx
*b0++ = *b1++; // say line #yy
...


and the assembly instruction corresponding to it is:


...
lc = 100;
rep(lc) *b0++ = *b1++;
...


I set the breakpoint to both of these lines xx & yy.


Now when I am at XX, I say 'Continue'. If it steps first

then it comes to


line #yy. Then if it continues, then I will not see my

program stopping at


YY where it should.


Or is it like, before proceeding from line #YY the debugger

looks for some


traps present at that particular line and then continues..


Pl. correct me if I am wrong.


If compiler optimization causes the loop to be executed as a single machine instruction (as in your example), then there is
nothing GDB can do about it. GDB's behavior would be to stop
after the loop finishes because the loop is actually one machine
instruction. This seems reasonable to me.

--Mark





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