Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Tim Combs <tcombs@urbana.css.mot.com>
To: anocean@aromasoft.com
Cc: "'Michael Eager'" <eager@eagercon.com>, gdb@sources.redhat.com
Subject: Re: gdb supports dwarf2 which is generated by ADS compiler?
Date: Thu, 08 Jan 2004 14:10:00 -0000	[thread overview]
Message-ID: <20040108080956.B23750@urbana.css.mot.com> (raw)
In-Reply-To: <000001c3d5e9$11b95240$f617203d@bathory>; from jaewoo.jang@aromasoft.com on Thu, Jan 08, 2004 at 10:12:28PM +0900

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


  reply	other threads:[~2004-01-08 14:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-07  7:07 Jang, Jaewoo
2004-01-07 17:15 ` Michael Eager
2004-01-08  4:06   ` Jang, Jaewoo
2004-01-08 13:12     ` Jang, Jaewoo
2004-01-08 14:10       ` Tim Combs [this message]
2004-01-08 14:12         ` Daniel Jacobowitz
2004-01-08 14:10       ` Daniel Jacobowitz
2004-01-09 14:30         ` Jang, Jaewoo
2004-01-08 23:46 ` Jim Blandy
2004-01-09 17:16   ` Michael Eager
2004-01-09 22:30     ` Tim Combs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040108080956.B23750@urbana.css.mot.com \
    --to=tcombs@urbana.css.mot.com \
    --cc=anocean@aromasoft.com \
    --cc=eager@eagercon.com \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox