From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20799 invoked by alias); 8 Jan 2004 14:10:00 -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 20751 invoked from network); 8 Jan 2004 14:09:59 -0000 Received: from unknown (HELO motgate4.mot.com) (144.189.100.102) by sources.redhat.com with SMTP; 8 Jan 2004 14:09:59 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i08E9plA000356 for ; Thu, 8 Jan 2004 07:09:51 -0700 (MST) Received: from udc.urbana.css.mot.com (udc.urbana.css.mot.com [192.88.153.21]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i08E7sal022439 for ; Thu, 8 Jan 2004 08:07:54 -0600 Received: from tmclinux.urbana.css.mot.com (tmclinux.urbana.css.mot.com [192.88.153.36]) by udc.urbana.css.mot.com (8.11.7p1+Sun/8.11.6) with ESMTP id i08E9v001499; Thu, 8 Jan 2004 08:09:57 -0600 (CST) X-POPI: The contents of this message are Motorola Internal Use Only (MIUO) unless indicated otherwise in the message. Received: (from tcombs@localhost) by tmclinux.urbana.css.mot.com (8.11.6/8.11.6) id i08E9vT23787; Thu, 8 Jan 2004 08:09:57 -0600 Date: Thu, 08 Jan 2004 14:10:00 -0000 From: Tim Combs To: anocean@aromasoft.com Cc: "'Michael Eager'" , gdb@sources.redhat.com Subject: Re: gdb supports dwarf2 which is generated by ADS compiler? Message-ID: <20040108080956.B23750@urbana.css.mot.com> References: <000801c3d59c$b468b000$f617203d@bathory> <000001c3d5e9$11b95240$f617203d@bathory> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <000001c3d5e9$11b95240$f617203d@bathory>; from jaewoo.jang@aromasoft.com on Thu, Jan 08, 2004 at 10:12:28PM +0900 X-SW-Source: 2004-01/txt/msg00084.txt.bz2 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. 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. Tim On Thu, Jan 08, 2004 at 10:12:28PM +0900, Jang, Jaewoo wrote: > > I am concerned for not reading my words because they are below replys. > > I wrote as > > As Trace32 debugger can also read the elf file which is > generated by ADS, > I think the elf file is not far from DWARF spec. > > But ADS debugger(adw) can not read gdb's elf file. > I am curious that gdb can support DWARF spec correctly. > > Anyway, I just have one question. > does gdb support this particular output from ADS? > (I don't think DWARF generated by ADS is not correct.) > > > > > -----Original Message----- > > From: gdb-owner@sources.redhat.com > > [mailto:gdb-owner@sources.redhat.com] On Behalf Of Jang, Jaewoo > > Sent: Thursday, January 08, 2004 1:06 PM > > To: 'Michael Eager' > > Cc: gdb@sources.redhat.com > > Subject: RE: gdb supports dwarf2 which is generated by ADS compiler? > > > > > > > > Thanks for your response. > > > > > -----Original Message----- > > > From: Michael Eager [mailto:eager@eagercon.com] > > > Sent: Thursday, January 08, 2004 2:15 AM > > > To: anocean@aromasoft.com > > > Cc: gdb@sources.redhat.com > > > Subject: Re: gdb supports dwarf2 which is generated by ADS compiler? > > > > > > > > > Jang, Jaewoo wrote: > > > > I try to debug elf dwarf2 format whcih is generated by ADS 1.0.1 > > > > compiler. It seems that gdb support dwarf2 spec. But ARM > > > dwarf2 spec > > > > is somehow modified from drawf2 spec. This is the reference of ARM > > > > dwar2 spec. > > > http://www.linuxbase.org/spec/refspecs/dwarf/ARMDwarf2.pdf > > > > > > > > > The ARM document specifies how their compiler generates > > > DWARF. They describe the choices which they make, as well as > > > the very minor areas in which they diverge from the DWARF 2 > > standard. > > > > > > > I want to know whether gdb will support ARM dwarf2 > > format, or it is > > > > possible to patch gdb that support ARM dwarf format. > > > > > > There is no ARM DWARF 2 format, as such. DWARF is permissive > > > -- it allows compilers to generate more or less information. > > > The ARM document does what few other compilers do: explain > > > what choices they made and their rationale. > > > > > > On the other hand, if a compiler generates DWARF which > > > diverges from the standard, one has to expect that a debugger > > > will have trouble interpreting it. I don't think that ADS > > does this. > > > > > > > As Trace32 debugger can also read the elf file which is > > generated by ADS, > > I think the elf file is not far from DWARF spec. > > > > But ADS debugger(adw) can not read gdb's elf file. > > I am curious that gdb can support DWARF spec correctly. > > > > > If you have a specific question (i.e., "does gdb support this > > > particular output from ADS?" or "is this particular DWARF > > > generated by ADS correct?"), then you will more likely get a > > > more specific response. > > > > > > > Anyway, I just have one question. > > does gdb support this particular output from ADS? > > (I don't think DWARF generated by ADS is not correct.) > > > > > > Now I try to understand source codes that is part of reading elf > > > > format. It is hard to understand. :( > > > > > > > > please help me. > > > > > > > > Sorry for my bad writing. > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > > Let's get rock. > > > > +82 (2) 3284-2463 anocean@aromasoft.com > > > > > > > > > > > > > --