This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: handle case arising from GCC PR 47510
On Wed, 02 Feb 2011 23:03:55 +0100, Tom Tromey wrote:
> Tom> +public:
> Tom> + C() {}
> Tom> + ~C() {}
>
> Jan> If the destructor is not present maybe_smash_one_typedef() will not
> Jan> work. And GDB crashes now due to it, that should be
> Jan> sanity-protected anyway.
>
> The class C is not the problem in this test case. I think C just exists
> to make sure that the "anonymous" struct is not a POD.
>
> maybe_smash_one_typedef won't be called for C, because C has a name.
>
> I don't understand about GDB crashing now due to C.
C itself isn't a problem. But as C no longer has a destructor even `t' no
longer has an implicit destructor. Due to it maybe_smash_one_typedef gets
called for `t' but it does not do anything as it does not find the '~' field.
Then cp_lookup_nested_type crashes as TYPE_TAG_NAME (parent_type) == NULL
- which is correct for anonymous struct - but cp_lookup_nested_type does not
expect it.
> Jan> I do not fully grok this change, it goes half way. Why two
> Jan> artificial methods are not non-unique?
>
> My understanding is that this loop is trying to filter out artificial
> methods in a case like:
>
> class K {
> K(int) { ... }
> };
>
> Here, I think, the user can type "ptype K::K" and get "K::K(int)" --
> which makes some kind of sense, ignoring the compiler-generated
> K::K(void). At least, that is what I think it all means. I am not sure
> this code is really correct, but this part of the patch is just avoiding
> a crash.
>
> I don't think it is possible for this loop to see two artificial
> methods.
I thought about:
class C { public: C() {} };
class CC { C cf; } cc;
class D : CC {} d;
int main () {}
built with:
GNU C++ 4.4.6 20110124 (prerelease)
producing:
nm -C file
00000000004005ac W CC::CC()
0000000000400592 W CC::CC()
GDB HEAD:
(gdb) p CC::CC
Cannot reference virtual member function "CC"
GDB with your patch:
(gdb) p CC::CC
$1 = {void (CC * const)} 0x400592 <CC::CC()>
(that is the 0x4005ac function is not shown to the user)
But this problem is not related to this patch as it happens even with
non-artificial constructors. lookup_symbol_aux_symtabs just returns the first
matching symbol. But one cannot specify demangled name for specific kind of
ctor/dtor so lookup_symbol_aux_symtabs must not error on non-unique match.
g++-4.5+ no longer generates multiple kinds of constructors during my tests so
it should not be much a real world concern anymore.
value_struct_elt_for_reference in this case sees only a single CC::CC entry as
the abstract structure itself has only one DIE for CC::CC.
So not an applicable issue for this patch.
Thanks,
Jan