Re: C++ support improvement patch

[Daniel Jacobowitz <drow at false dot org>]

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.

On Mon, Jan 23, 2006 at 10:50:40AM +0100, Thomas Richter wrote:
> 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!

Also, what version of GCC were you testing against?

> 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.

> 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.

> 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'".

> 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.

> 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.

-- 
Daniel Jacobowitz
CodeSourcery