From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22214 invoked by alias); 8 Jan 2004 14:12:30 -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 22204 invoked from network); 8 Jan 2004 14:12:30 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 8 Jan 2004 14:12:30 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1Aeatd-0004QX-Ng; Thu, 08 Jan 2004 09:12:25 -0500 Date: Thu, 08 Jan 2004 14:12:00 -0000 From: Daniel Jacobowitz To: Tim Combs Cc: anocean@aromasoft.com, 'Michael Eager' , gdb@sources.redhat.com Subject: Re: gdb supports dwarf2 which is generated by ADS compiler? Message-ID: <20040108141225.GB16913@nevyn.them.org> Mail-Followup-To: Tim Combs , anocean@aromasoft.com, 'Michael Eager' , gdb@sources.redhat.com References: <000801c3d59c$b468b000$f617203d@bathory> <000001c3d5e9$11b95240$f617203d@bathory> <20040108080956.B23750@urbana.css.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040108080956.B23750@urbana.css.mot.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00086.txt.bz2 On Thu, Jan 08, 2004 at 08:09:57AM -0600, Tim Combs wrote: > The dwarf2 generated by the ADS compiler has only limited supported from GDB. > especially from a C++ perspective. The problem is in the way the compilation > units are created by the ADS compiler. > > When GCC creates a compilation unit (at least in my example programs), the > class definition contained in the header file and the member functions are > in a single compilation unit. > > When ADS generates a compilation unit that contains a function, it also > generates compilation units containing the definition of all the header > files included in the function file. I've been trying to work on a > problem with C++ classes in particular and so from a C++ perspective, > this creates a problem because the class definition is not in the same > compilation unit as the member functions. > > These function definitions usually use either an AT_TAG_specifiction or > an AT_TAG_abstract tag that refers that uses a location description that > points to the definition of the function and the class which it belongs. > When a user sets a breakpoint, GDB will go looking for the psymtab > that contains the address its looking for. It then parses the debugging > information in *that* compilation unit. Because of that, > GDB doesn't process the "header" compilation unit that has the definition > of the class. So the class definition from GDB's perspective only > contains the member functions that were contained the compilation > unit that was parsed. Again, from a C++ perspective, this means that > public and private as well as inherited class variables cannot be seen. OK, thanks. This problem is expected to get fixed this year... I hope. It's been on our todo list for ages. > Then, there is another problem, at least with the 1.2 compiler in that if > the "this" pointer is not explicitly used in the code, Arm will generate > a __this pointer. So GDB's lookup function that's hard coded to look for > "this" fails. I'd have to see a complete sample to decide what to do about this... but that's lower priority than the previous issue. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer