This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: C++ and multiple compilation units


Jim Blandy <jimb@zwingli.cygnus.com> writes:

> Dan, a while back I think you mentioned a problem that would only
> appear when debugging C++ programs using Dwarf 2 debug info that used
> multiple compilation units.  I think the issue was that our current
> dwarf 2 reader doesn't really handle inter-CU DIE references, and that
> GCC was going to start generating them. 

Yup.
>  Our current C++ tests
> probably won't catch such a problem --- almost all of the test
> programs are a single CU.
> 
> Can you give more details on this? 
Sure.

To do elimination, you need inter-cu die references, so you can refer
to previous existing DIEs/ use linkonce sections, etc.

In fact, dwarf2.1 adds an imported_unit/partial_unit tag so that you can comdat
just about everything, and not screw up the scope (partial_unit means
ignore it when scanning toplevel cu's, we read it in when we see the
imported_unit tag))
>  Does GCC generate these inter-CU
> references now? 

No, but only because GDB can't handle them
Let me rephrase that. It *can* generate them, it just defaults to not doing so.
-feliminate-dwarf2-dups is the flag to turn it on.

>  For what sorts of constructs?
Currently it comdats symbols likely to be shared, if
-feliminate-dwarf2-dups is on. This is based on dwarf2 elimination,
i'm going to be modifying it soon to use the dwarf2.1 partial/imported
unit stuff, to do even more elimination.

In the future, it'll just do what the dwarf2.1 standard says in the
appendix (which is based on starting from what gcc did, and improving
a bit, using section groups and a new tag to specify an imported unit) 
>   Do you have a test case?
I can easily generate them, if you like. It's pretty trivial.

The inter-die cu references is what started the need the rewrite.  We assume
everywhere we are only processing the current CU, and never have to
move between them. 
So i rewrote the whole damn thing to pass around a structure that
contains the compilation unit context to do whatever in.  When we need
to switch between compilation units, we just change the context we are
passing around, reading in the abbrevs/whatever for that cu if
necessary.


--Dan

-- 
"I have the oldest typewriter in the world.  It types in pencil.
"-Steven Wright


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]