From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: Daniel Berlin Cc: gdb@sources.redhat.com Subject: Re: C++ and multiple compilation units Date: Wed, 18 Jul 2001 15:51:00 -0000 Message-id: References: <20010717200447.24E1A5E9D8@zwingli.cygnus.com> <87n1631apn.fsf@cgsoftware.com> X-SW-Source: 2001-07/msg00262.html Daniel Berlin writes: > 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)) This is new in Draft 6, right? > > 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. Okay. > > Do you have a test case? > I can easily generate them, if you like. It's pretty trivial. That would be really helpful. > 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. That's right. > 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. But once we've called read_comp_unit, we're not going any more I/O --- we've turned the whole CU into a linked list (which should be a tree) of `struct die_info' nodes. So if we find a reference to another compilation unit, it seems to me we could just call read_comp_unit again, and extend our die list (and reference table). We'd need a map of where each compilation unit starts and ends, so we could tell which CU to read when we find a reference that falls outside of our own. But that's easily produced when we build the partial symbols. Suppose further that we restructured `struct die_info' to be a real tree, not a linked list whose tree structure is only apparent from the presence of null dies. Each die could have a parent pointer, which would allow us to produce scoped names. This *sounds* a bit simpler than your changes. But I haven't actually done the work, so I can't be sure.