From: Ramana Radhakrishnan <ramana.radhakrishnan@codito.com>
To: "Manoj Verma, Noida" <manojv@noida.hcltech.com>, gdb@sources.redhat.com
Subject: Re: remote debugging packets
Date: Sat, 22 Nov 2003 09:26:00 -0000 [thread overview]
Message-ID: <3FBF2C47.3030901@codito.com> (raw)
In-Reply-To: <1B3885BC15C7024C845AAC78314766C5010336EC@EXCH-01>
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
>>
>>
>>
next prev parent reply other threads:[~2003-11-22 9:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-22 8:44 Manoj Verma, Noida
2003-11-22 9:26 ` Ramana Radhakrishnan [this message]
2003-11-22 13:46 ` Mark Salter
-- strict thread matches above, loose matches on Subject: below --
2003-11-21 15:15 Manoj Verma, Noida
2003-11-21 16:06 ` Mark Salter
2003-11-21 14:32 Manoj Verma, Noida
2003-11-21 14:52 ` Mark Salter
2003-11-21 14:00 Manoj Verma, Noida
2003-11-21 14:25 ` Mark Salter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3FBF2C47.3030901@codito.com \
--to=ramana.radhakrishnan@codito.com \
--cc=gdb@sources.redhat.com \
--cc=manojv@noida.hcltech.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox