From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23913 invoked by alias); 15 Nov 2002 23:04:46 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 23905 invoked from network); 15 Nov 2002 23:04:45 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 15 Nov 2002 23:04:45 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id gAFN4YU12823; Fri, 15 Nov 2002 15:04:34 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Elena Zannoni Cc: gdb@sources.redhat.com, Daniel Berlin Subject: Re: gdb/829: GDB doesn't know about using directives References: <20021115214250.5407.qmail@sources.redhat.com> <15829.28869.815420.590217@localhost.redhat.com> From: David Carlton Date: Fri, 15 Nov 2002 15:04:00 -0000 In-Reply-To: <15829.28869.815420.590217@localhost.redhat.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-11/txt/msg00185.txt.bz2 On Fri, 15 Nov 2002 17:10:13 -0500, Elena Zannoni 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