* Re: gdb/829: GDB doesn't know about using directives
2002-11-15 14:17 ` gdb/829: GDB doesn't know about using directives Elena Zannoni
@ 2002-11-15 15:04 ` David Carlton
0 siblings, 0 replies; 2+ messages in thread
From: David Carlton @ 2002-11-15 15:04 UTC (permalink / raw)
To: Elena Zannoni; +Cc: gdb, Daniel Berlin
On Fri, 15 Nov 2002 17:10:13 -0500, Elena Zannoni <ezannoni@redhat.com> said:
> carlton@math.stanford.edu writes:
>> >Fix:
>> A good first step would be for GCC to generate the appropriate
>> debugging information...
> Ahem, cough cough.....
> Could you expand a bit on this?
> What is missing? I was blissfully unaware of this. Having such a
> dependency could delay a fix noticeably.
Current versions of GCC don't generate debugging information for
namespaces and related C++ constructs (using directives, using
declarations, namespace aliases). Their excuse was that GDB would get
seriously confused by the DW_TAG_namespace entries, and without those
entries GCC also can't generate DW_TAG_imported_module and
DW_TAG_imported_declaration entries. I've gotten a patch into GDB 5.3
that will allow GDB not to be confused by those entries, so the way is
clear for GCC to generate the correct info.
Daniel Berlin has a patch to get GCC to generate entries for
namespaces (and, I believe, for namespace aliases, though I haven't
tested that aspect of the patch); my understanding is that this patch
should make it into GCC 3.3. I've been testing my current work both
with and without this patch. Daniel has another patch that handles
some of the other cases (I'm not sure exactly what it handles - I
don't think I have the latest version of his patch), but unfortunately
that patch is noticeably messier, because GCC's C++ front end
currently doesn't provide the right information to it's back end. It
currently looks like GCC won't provide full debugging information for
these constructs until GCC 3.4: according to Daniel, Mark Mitchell
wants to wait until the C++ front end is cleaned up a bit before
providing that information. (I could be wrong about this: Daniel,
feel free to correct me if I've misspoken.) I'll be happy to work
with whatever messy patch Daniel or somebody else can provide to me,
as long as it causes GCC to generate the correct debugging
information; it seems not unlikely to me that GDB will be able to make
use of full debugging information some time before released versions
of GCC are able to generate it.
There are workarounds for the lack of debugging information in some
circumstances: GDB knows what the full demangled names of variables
look like, after all, so it can tell when, for example, a function is
defined in a namespace. It can also use this to sniff out the
existence of anonymous namespaces. So I'm telling GDB to do so, when
possible: if the object file in question seems to have full debugging
information, then GDB relies on that, but otherwise it tries to deduce
the correct information on its own.
Unfortunately, the situations where GDB can't figure out the correct
information are also the situations where it will take the longest for
GCC to provide the correct information. For example, there is no way
for GDB to tell that code contains a using directive unless GCC puts
that information in the debugging info: using directives leave no
trace anywhere else in the object code. Fortunately, users can work
around that (basically by qualifying the names they type in more
completely), but it's still annoying for users trying to debug code
that, say, uses heavily nested namespaces.
My opinion is that probably the most crucial situations are having GDB
know what scope a function is defined in (because you're typically
inspecting variables from within the body of a function, and as long
as the variables you're inspecting live in namespaces related to the
namespace that your function is defined in, you don't have to type
_too_ much), and also having GDB figure out anonymous namespaces
(because the workaround for that is non-obvious and it's annoying even
after you've learned it). And I've modified GDB to figure those out
reasonably well on its own.
In the PR's, I'm only mentioning GCC's shortcomings in situations
where GDB doesn't have any good workaround for the absence of
debugging info.
If it's important for somebody to have versions of GCC/GDB that can
handle all of these constructs acceptably within the next few months
or half year or so, probably that person should contact Daniel Berlin
to get a copy of his GCC patch, contact me just to let me know what's
up, and do whatever's necessary to get Daniel's patch working
completely (if anything). (I'll happily accept bribes, too. :-) )
David Carlton
carlton@math.stanford.edu
^ permalink raw reply [flat|nested] 2+ messages in thread