Re: So what is wrong with v3 C++

[Daniel Berlin <dan at cgsoftware dot com>]

Andrew Cagney <ac131313@cygnus.com> writes:

> So,
> 
> [Perhaphs I should write a book about how I'm a reformed C++
> programmer ... :-)]
> 
> 
> At the risk of ``playing manager'', I'd like to try to understand
> exactly what the problems with GDB v3.0 are.  If nothing else, I, or
> someone else, will need to document these as known bugs in the 5.1
> release notes.  Further, since C++ no longer has a maintainer, I think
> that now is probably a good time to take stock.
Sure, i'll avoid discussion of other problems, and just stick the v3
ones, so that i don't end up writing a novel.
:)

> 
> 
> 
> Anyway, to this end, I had a face to face discussion with Jim Blandy
> (Don and a few others were present and were contibuting, unfortunatly,
> neither DanB nor Michael C were around).
> 
> 
> In that discussion, my attention was drawn to the following v3 C++ problems:
> 
> 
>> - Dwarf 2 reader: fix constructor stuff
>>   (http://sources.redhat.com/ml/gdb/2001-06/msg00096.html)
> 
> 
> While this has been discussed to death and causes many many failures
> and a fix involves changes to the dwarf2 reader.  I'm left wondering
> if:
> 
> 
> 	o	it really needs a dwarf2 rewrite
Yes.
There is no other way to do it properly.  
The constructors involved have no mangled name, so you need to be able
to generate a fully qualified name. You couldn't do this easily
without rewriting most of the dwarf2 reader anyway, and as i'll
explain a little below, it's badly in need of a rewrite anyway.

To put it into a picture, it looks like this:


DW_TAG_class:
        DW_AT_name: bob
        ...
        DW_TAG_member:
                DW_AT_name: bob
        ...
DW_TAG_subroutine:
        DW_AT_specification: <pointer to the bob member>
        ...

See, normally, their is a very bad hack involved here so that we don't
just call the thing inside the class "bob", we call it "bob::bob".

This is the DW_AT_mips_linkage_name hack.  It gives a mangled name.
The mangled name, once demangled, is fully qualified.  We use this
hack (which doesn't even work completely) to get some semblance of a
right name.

However, since the *real* constructor subroutine die (the one outside
the class) points to a die inside the class, which has no
linkage_name, we call the constructor "bob" (if an attribute doesn't
exist in the same die, you see if it exists in the specification die).

The inside the class constructor *can't* have a linkage name.  It's
really two different constructors, and doesn't exist for real.

But because we rely on mangled names to give us the qualified names,
instead of *scoping*, we give the name "bob" to the constructor.

In other words, we've always had this problem, it just wasn't so damn
easy to see before.


> 
> 	o	compared to some of the other
> 		bugs, it is really that urgent
> 
> Personally, I'd be more worried about being able to single step and
> print variables correctly.

You can't do either with the scoping problems involved.
Read benjamin's bug report from yesterday.

> 
> 
> 
> 
>> - Virtual base classes, and their virtual functions
> 
> 
> This, I understand is more serious.  GDB does need to be able to print
> out virtual base classes, their functions and so on.  I understand
> that, at present, it prints out bogus information.
> 
> 
> Going by what Jim indicated, though, this in theory just involves more
> foot leather - finding the time to fill in the missing cases. 

Sure.
>  I
> suspect that who ever does do this will need very thick soles on their
> shoes.
> 
> 
> 
>> - Skipping vtable thunks, if necessary
> 
> 
> I don't know if this was ever discussed on this list.  As I understand
> it, v3 virtual function is sometimes called via a ``thunk''.  A
> ``thunk'' pulls a rabbit out of a hat (finds the correct object to
> pass to the real function) and then passes control to the real
> function.
> 
> 
> At present, if GDB stepped into a thunk it would find no line info,
> treat it like a library and just skip it - oops, step into virtual
> functions via thunks doesn't work.
> 
> 
> One proposed solution is to mimic / generalize the shared library
> mechanism so that GDB will single step through it to the real
> function.
> 
> 
> I think this bug is pretty serious since, GDB will, randomly loose
> control over the target.  I certainly think it is more serious than
> the constructor problem.

Sure.
But the constructor problem is caused by a much larger problem, of
arguably equal importance.
That is, the lack of proper qualifying of names done by the dwarf2
reader.

Note that the STABS reader is hopeless in this regard.
It'll always have to depend on mangled names, and thus, you can't do
anything about the generation of qualified names.

> 
> 
> 
>> - Breakpoint work?
> 
> 
> This one I don't remember.  There was a question if, given an
> arbitrary C++ expression, GDB could find and set a breakpoint on the
> correct function.

Yes, but only thanks to overloading support.

It doesn't, however, do it automatically, and it could.

> 
> 
> 
>> - decode_line_1
> 
> 
> This one has been discussed to death.  The current decode_line_1 is
> un-maintainable.  However, people, are largely living with it.
> 
> 
> 
> So my first question.  Are there any other serious v3 bugs? 

Yes.
The scoping problems caused by the way the current dwarf2 reader does
it's thing cause us to misname variables, functions, nested classes,
you name it.

As benjamin's simple case shows, you end up with numpunct<char>
instead of std::numpunct<char>.

Their is also the problem that baseclasses will not be offset properly
all the time.  So printing out variables of a class type may display
completely bogus info.

IE

(gdb) print a
{<A> = { a = 598713412, b=5917212}}

Where a and b should be "6" and "3".
:)


>  MichaelC,
> you're probably most familar with the testsuite and what it is
> reporting as broken.
> 
> 
> My second question.  How many of these bugs can be fixed without
> rewriting the dwarf2 reader?

Anything that is generic, and doesn't involve scoping, can be fixed
without rewriting the dwarf2 reader. In fact, rewriting the dwarf2
reader won't help them.

However, the dwarf2 reader was in bad need of a rewrite anyway.
It didn't even support all of dwarf2 properly, wasted tons of memory,
and couldn't possibly support dwarf2 if it tried, 
let alone be maintainable in the future.  It's a hacked up dwarf1
reader right now.

You speak of rewriting the dwarf2 reader as if it was a large body of
work that needed to be completed.
I'm about to submit it for approval in a few minutes.
In other words, it's pretty much done.
Bug fixes remain, i'm sure, but all functionality is now complete.
It qualifies names without relying on mangled names, properly manages
memory, can support all of dwarf2, and 2.1, etc.

>  My understanding is that both the
> virtual functions and the thunks bugs can.
Yup.

And the baseclass offset one can too.
But it's not particularly fun or easy to do.


Note that i only mention fixing the dwarf2 reader because you *can't*
fix the stabs reader, unless you introduce support for namespaces into
stabs, etc.
It's not worth the work.


> 
> 
> enjoy,
> 	Andrew
> 
> 

-- 
"I got a new shadow.  I had to get rid of the other one...  It
wasn't doing what I was doing.
"-Steven Wright