This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdb supports dwarf2 which is generated by ADS compiler?


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
> > > > 
> > > 
> > > 
> > > -- 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]