Strange effect in GDB 6.8 when setting breakpoint on symbol with both strong and weak definitions

Strange effect in GDB 6.8 when setting breakpoint on symbol with both strong and weak definitions

[Antony KING]

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.

Re: Strange effect in GDB 6.8 when setting breakpoint on symbol with both strong and weak definitions

[Daniel Jacobowitz]

On Tue, Oct 14, 2008 at 02:23:52PM +0100, Antony KING wrote:
> 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 ?

I don't know why this happens.

> 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) ?

It would be nice if this worked, but it doesn't; so far it's only
based on line number.  So it works for inlined or templated code.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Strange effect in GDB 6.8 when setting breakpoint on symbol with both strong and weak definitions

[Antony KING]

Daniel Jacobowitz wrote:
> On Tue, Oct 14, 2008 at 02:23:52PM +0100, Antony KING wrote:
>> 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 ?
> 
> I don't know why this happens.

I have also just tried this with the CVS HEAD of GDB with the same
result. Could it be that GDB is re-evaluating the breakpoint after the
program is launched (since it is a pending breakpoint) and a different
instance of f() being found ?

BTW when I use our build of GDB 6.8 for use with remote SH-4 targets I
do not see this "shift" of breakpoint location.

Anyway, I think I will submit this behaviour as 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) ?
> 
> It would be nice if this worked, but it doesn't; so far it's only
> based on line number.  So it works for inlined or templated code.

OK. I do not remember seeing anything recently on the GDB list about
this, but is this an area being looked at as a future enhancement ?

Re: Strange effect in GDB 6.8 when setting breakpoint on symbol with both strong and weak definitions

[Daniel Jacobowitz]

On Tue, Oct 14, 2008 at 09:30:42PM +0100, Antony KING wrote:
> I have also just tried this with the CVS HEAD of GDB with the same
> result. Could it be that GDB is re-evaluating the breakpoint after the
> program is launched (since it is a pending breakpoint) and a different
> instance of f() being found ?

Yes, that's pretty likely.  There may not be much about it.

> OK. I do not remember seeing anything recently on the GDB list about
> this, but is this an area being looked at as a future enhancement ?

I agree that it should be improved, but I do not think anyone is
planning to work on it.

-- 
Daniel Jacobowitz
CodeSourcery