From: Antony KING <antony.king@st.com>
To: gdb@sourceware.org
Subject: Strange effect in GDB 6.8 when setting breakpoint on symbol with both strong and weak definitions
Date: Tue, 14 Oct 2008 13:24:00 -0000 [thread overview]
Message-ID: <48F49D68.2030701@st.com> (raw)
Consider the following source files a.c and b.c:
== a.c ==
#include <stdio.h>
void f(void) __attribute__((weak));
void f(void)
{
printf("FAIL\n");
}
int main(void)
{
f();
return 0;
}
== a.c ==
== b.c ==
#include <stdio.h>
void f(void)
{
printf("PASS\n");
}
== b.c ==
If I compile them (on RHEL3 but I don't think this is significant) using
"gcc -g a.c b.c" and then debug the resulting executable using the
following GDB script:
file a.out
set trace-commands 1
break f
tbreak main
info breakpoints
run
info breakpoints
break f
continue
I see the following output from GDB:
> +break f
> Breakpoint 1 at 0x8048382: file b.c, line 5.
> +tbreak main
> Breakpoint 2 at 0x8048369: file a.c, line 11.
> +info breakpoints
> Num Type Disp Enb Address What
> 1 breakpoint keep y 0x08048382 in f at b.c:5
> 2 breakpoint del y 0x08048369 in main at a.c:11
> +run
> main () at a.c:11
> 11 f();
> +info breakpoints
> Num Type Disp Enb Address What
> 1 breakpoint keep y 0x0804834a in f at a.c:5
> +break f
> Breakpoint 3 at 0x804834a: file a.c, line 6.
> +info breakpoints
> Num Type Disp Enb Address What
> 1 breakpoint keep y 0x0804834a in f at a.c:5
> 3 breakpoint keep y 0x0804834a in f at a.c:6
> +continue
> PASS
>
> Program exited normally.
As you can see the location of the breakpoint at f() has been shifted
from its definition in b.c (which is what I expected) before the program
is run, to its definition in a.c after the program stopped in main()
(which is not what I would expect). This shift of location seems wrong
to me and quite unexpected. Is this a bug ?
Another problem is that although there are 2 definitions of f() in the
program, only 1 breakpoint is being set. My understanding is that GDB
should set multiple breakpoints on f(). Is this correct (or is this only
a feature that is enabled when debugging C++ applications) ?
[The application I am trying to debug is more complicated embedded
application running on an SH-4 CPU but the example above illustrates the
problems I am encountering.]
Thanks for any illumination.
Cheers,
Antony.
next reply other threads:[~2008-10-14 13:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-14 13:24 Antony KING [this message]
2008-10-14 13:31 ` Daniel Jacobowitz
2008-10-14 20:31 ` Antony KING
2008-10-15 1:30 ` Daniel Jacobowitz
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=48F49D68.2030701@st.com \
--to=antony.king@st.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