Re: [gdb-7.1] 10 days to branching...

[Pedro Alves <pedro@codesourcery.com>]

Thanks for taking care of this.

On Friday 12 February 2010 06:15:58, Joel Brobecker wrote:
> > |       sym_arr[i1] = lookup_symbol_in_language (phys_name,
> > |                                    NULL, FUNCTIONS_DOMAIN,
> > |                                    language,
> > |                                    (int *) NULL);
> > | -      if (sym_arr[i1])
> > | +      /* See PR10966.  Remove check on symbol domain and class when
> > | +         we stop using (bad) linkage names on constructors.  */
> > | +      if (sym_arr[i1] && (SYMBOL_DOMAIN (sym_arr[i1]) == VAR_DOMAIN
> > | +                          && SYMBOL_CLASS (sym_arr[i1]) == LOC_BLOCK))
> > |         i1++;
> 
> Tested with no regression on my end. Regarding my C++ compiler quality,
> I looked at gdb.sum, and I have 32 KFAILs and 20 FAILs in gdb.cp.
> However, upon further testing, it appears that the patches does not
> have the desired effect (or I applied it at the wrong location?):
> 
>     (gdb) b Foo::Foo
>     the class Foo does not have any method named Foo
>     Hint: try 'Foo::Foo<TAB> or 'Foo::Foo<ESC-?>
>     (Note leading single quote.)
>     Make breakpoint pending on future shared library load? (y or [n]) n
> 

This is what I'd expect.  In previous GDBs, if there's only one
contructor, like, say:

struct Foo
{
	Foo()
	{}
};

Foo foo;

int main (int argc, char **argv)
{
	return 0;
}

GDB would just do nothing in response to that command.

(gdb) b Foo::Foo
(gdb)

If you had multiple constructors, say:

struct Foo
{
	Foo()
	{}
	Foo(const char *foo)
	{}
};

Foo foo;
Foo bar("bar");

int main (int argc, char **argv)
{
	return 0;
}

GDB would create broken breakpoints for them at address 0...

(gdb) b Foo::Foo
[0] cancel
[1] all
?HERE
?HERE
>

"?HERE" was never supposed to be visible to the user, and should
have been replaced by the proper name for the
function (the constructors), but since GDB found the wrong symbol...

> 1
Breakpoint 2 at 0x0
Breakpoint 3 at 0x0
warning: Multiple breakpoints were set.
Use the "delete" command to delete unwanted breakpoints.
(gdb) info breakpoints
Num     Type           Disp Enb Address            What
2       breakpoint     keep y   0x0000000000000000
3       breakpoint     keep y   0x0000000000000000

Not very useful either.

That happens is that the wrong symbols are found, and a
broken sal escapes to the breakpoints module.  Nowadays,
there's an assertion that catches this (without the
assertion, we'd crash instead).


Note that even with the workaround, this still works:

 (gdb) b 'Foo::Foo()'
 Breakpoint 2 at 0x8048455: file foo.cc, line 3.
 (gdb) b 'Foo::Foo(const char *)'
 Breakpoint 3 at 0x804845b: file foo.cc, line 5.

It's the Foo::Foo form that's been broken for ages:

 (gdb) p Foo::Foo
 Cannot look up value of a typedef


I just tried GDB 5.3 and 6.0, and they seem to get it
right though, so this was a regression at some point.  :-)

-- 
Pedro Alves