Re: C++ support improvement patch

[Thomas Richter <thor@mail.math.tu-berlin.de>]

Hi Daniel,

> Thanks for the patch.  There's a lot of bits that just change formatting
> or comments; it's making it a little hard for me to work out what
> changes do what.

I think parts of the comments are useful to understand what's going
on here. The most sensitive part is in symtab.c.

> > o) GDB finds now members within the multiple-inheritance hierarchy of
> > a class. That is, if "this" points to a class "Foo" inherited from
> > "Bar" and "Baz", and "Baz" contains a member "me", then "print me"
> > will succeed now. gdb 6.4 and before just returned an "unknown symbol"
> > here, erraneously. This is because it was confused by a "class typedef"
> > g++ inserted here for subclasses in the dwarf-2 symbol table, which is
> > now cleverly avoided. The patch then, however, needs to be clever to
> > resolve expressions like this->Subclass::member, which - after a bit
> > of work - now works nicely as it should. It seems to me that it worked
> > more or less by accident before (Subclass was resolved as the constructor
> > name, not as the class name.)
> 
> Can you give a testcase for this problem?  It should already work,
> and if it doesn't I want to know why!

It doesn't. Sorry, the code where it doesn't is part of a larger code
project I wouldn't really be able to send (and you wouldn't be willing
to check, either ;-), but I'll see whether I'll be able to setup a minimal
testcase.

> Also, what version of GCC were you testing against?

That's g++ 3.4.4, the g++ in Debian stable.

> > o) For TAB-expansion, it removes the ":" as word-delimiter for
> > readline, thus allowing to find names in namespaces. The current
> > behaivour here is completely unusable for C++. The patch could
> > be better, though, it should read template argument delimiters < >
> > and function argument delimiters ( ) as "quotation characters",
> > though it doesn't. Though it's a huge improvement compared to
> > previous versions where TAB expansion was just not usable for C++.
> 
> This isn't the right fix, though.  Someone posted (Pierre Muller, a
> long time ago - April 2002!) an initial patch to make tab completion
> context sensitive (for Pascal) - tab complete to the colon, type the
> colon, and then tab complete structure members after the colon.
> 
> It isn't suitable as-is and no one ever had time to go back and improve
> it but that's what ought to be done.

Thanks for letting me know that this is being worked on. I agree that
the given patch is pretty much a "hands on" approach. If there's a better
way to do it, please do. Otherwise, the patch is "better than nothing".

> > o) GDB now avoids to set multiple breakpoints to the same location.
> > This goes in conjunction with another bug, namely that of being unable
> > to find constructors of multiply-inherited classes. Without the current
> > patch, setting a breakpoint for a constructor results in multiple breakpoint
> > locations found, all of them identical, and none of them actually 
> > beeing breaked on. With the patch applied, GDB at least finds only one
> > of the locations (good), but still doesn't break there (bad). This bug
> > seems partially caused by g++ not emmiting mangled names for constructors.
> 
> Would be better not to return duplicates, instead of not putting
> duplicates on the list... we know exactly why this happens.  It's
> all part of the multiple constructors issue that you mentioned below,
> and you can find more information about this in the gdb@ list archives.

Could you provide a reference, please? Currently, the found symbols are
identically (in fact, it's even the same structure using the same pointer),
so I don't quite see what's the benefit as there's no chance of telling
them apart later. I get two breakpoints at the same location (then, breaking
nothing). In the long run, though, I agree and the problem should be fixed,
not the symptom.

> > o) GDB does no longer print the character and the value for integer values
> > of size one. It only prints the character. The reason for this is that
> > with the ddd frontend, ddd parses the output of "info breakpoints" to
> > set or reset breakpoints (e.g. when moving them in the sources). Without
> > the patch, the syntax of the output is no longer valid, and is not parsable
> > by gdb again.
> 
> This is what GDB has always done.  I admit it's strange in expressions.
> What I'd like to see would be only the value in expression printouts,
> without changing the (useful) output of "print 'c'".

Thus, a similar patch applied higher in the calling chain, within
"info"?

> > i) gdb relies on the "MIPS linkage name" of members, though according to
> > the g++ folks it should not,
> 
> I have patches to remove this dependence that I will be revisiting in
> 2006.

I personally wouldn't care unless I would be able to set breakpoints. (-;

> > ii) g++ may create separate constructors depending on whehter the class is
> > constructed by itself, or as part of a subclass. gdb seems to be unaware
> > of this. I've no idea how to resolve this.
> 
> As I mentioned above, please see the GDB list archives.  It was just
> discussed again recently and I have some hope that 2006 will see a
> solution.

That would be great!

So long, and thanks for the comments.

Thomas Richter