From: Brian Heilig <bheilig@etinternational.com>
To: gdb@sourceware.org
Subject: Re: Porting gdb to Cyclops64
Date: Tue, 03 Aug 2010 16:52:00 -0000 [thread overview]
Message-ID: <1280854337.1560.66.camel@random> (raw)
In-Reply-To: <201008021435.16106.pedro@codesourcery.com>
Guys, thanks again for all your help. My target is reporting events in a
sane order in stop mode now but I've run into a snag.
While debugging the following program:
#include <stdio.h> /* line 1 */
void foo(int *a) { /* line 2 */
*a = 9; /* line 3 */
} /* line 4 */
int main() { /* line 5 */
int a=0; /* line 6 */
foo(&a); /* line 7 */
printf("%d\n",a); /* line 8 */
return 0; /* line 9 */
}
I set a breakpoint at line 7. All threads hit that breakpoint. I stepped
thread 1 and continued the other threads.
[Switching to Thread 1]
Breakpoint 1, main () at step.c:7
7 foo(&a); /* line 7 */
(gdb) s
[Switching to Thread 2]
Breakpoint 1, main () at step.c:7
7 foo(&a); /* line 7 */
(gdb) c
Continuing.
[Switching to Thread 3]
... etc.
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 1]
0x0000000080800274 in main () at step.c:7
7 foo(&a); /* line 7 */
I switched back to thread 1 and step again:
(gdb) s
foo (a=0x41103ae8) at step.c:3
3 *a = 9; /* line 3 */
(gdb)
I step one more time and gdb switches to thread 2. Why is that?
(gdb) s
Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 2]
foo (a=0x41803ae8) at step.c:3
3 *a = 9; /* line 3 */
It turns out that when I stepped to line 3 (the second step) gdb
actually set a breakpoint at line 3. This might be because 'foo' has
been inlined. Then gdb told my target to continue all "vCont;c". All
threads hit the breakpoint, but only thread 1 should have.
I don't know how it's supposed to work, but gdb could have sent
"vCont;c:1". Or gdb could have single stepped until it reached the
correct address (obviously not the preferred method). How can I correct
this?
Thanks,
Brian
next prev parent reply other threads:[~2010-08-03 16:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-30 17:13 Brian Heilig
2010-07-30 17:26 ` Michael Snyder
2010-07-30 18:53 ` Brian Heilig
2010-07-30 18:57 ` Michael Snyder
2010-07-30 20:28 ` Brian Heilig
2010-07-30 22:54 ` Michael Snyder
2010-07-30 23:18 ` Pedro Alves
2010-08-02 13:25 ` Brian Heilig
2010-08-02 13:35 ` Pedro Alves
2010-08-03 16:52 ` Brian Heilig [this message]
2010-08-05 13:56 ` Brian Heilig
2010-08-05 14:19 ` Pedro Alves
2010-08-06 18:39 ` Problems with non-stop - " Brian Heilig
2010-08-30 19:44 ` Cyclops64 Multi-Process Brian Heilig
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=1280854337.1560.66.camel@random \
--to=bheilig@etinternational.com \
--cc=gdb@sourceware.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).