gdb supports dwarf2 which is generated by ADS compiler?

gdb supports dwarf2 which is generated by ADS compiler?

[Jang, Jaewoo]

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

I want to know whether gdb will support ARM dwarf2 format,
or it is possible to patch gdb that support ARM dwarf format.
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

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

[Michael Eager]

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.

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.

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


-- 
Michael Eager	 Eager Consulting     eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

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

[Jang, Jaewoo]

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
> > 
> 
> 
> -- 
> Michael Eager	 Eager Consulting     eager@eagercon.com
> 1960 Park Blvd., Palo Alto, CA 94306  650-325-8077
> 

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

[Jang, Jaewoo]

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
> > > 
> > 
> > 
> > -- 
> > Michael Eager	 Eager Consulting     eager@eagercon.com
> > 1960 Park Blvd., Palo Alto, CA 94306  650-325-8077
> > 
> 

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

[Daniel Jacobowitz]

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

How could we tell?  You didn't provide a sample, a dump, or any
information about "this particular output".

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Jang, Jaewoo]

[-- Attachment #1: Type: text/plain, Size: 1649 bytes --]


I am enclosing sample file.
The files in the zipped file are source code, and compiled executables.
"gcc.client" is compiled by GCC 3.2.1, and "ads.client" is compiled by ADS
1.0.1. I am using gdb version 6.0. The problem is arm-elf-gdb can not
disassamble ads.client correctly. There are some problem on checking ARM
mode and THUMB mode. I think that the problem is derived from reading dwarf2
format.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Let's get rock.
+82 (2) 3284-2463 anocean@aromasoft.com


> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> Sent: Thursday, January 08, 2004 11:11 PM
> To: anocean@aromasoft.com
> Cc: 'Michael Eager'; gdb@sources.redhat.com
> Subject: Re: gdb supports dwarf2 which is generated by ADS compiler?
> 
> 
> 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.)
> 
> How could we tell?  You didn't provide a sample, a dump, or
> any information about "this particular output".
> 
> --
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
> 

[-- Attachment #2: sample.tgz --]
[-- Type: application/x-compressed, Size: 4204 bytes --]

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

[Tim Combs]

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

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

[Daniel Jacobowitz]

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

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

[Jim Blandy]

"Jang, Jaewoo" <jaewoo.jang@aromasoft.com> writes:
> 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
> 
> I want to know whether gdb will support ARM dwarf2 format,
> or it is possible to patch gdb that support ARM dwarf format.
> Now I try to understand source codes that is part of reading elf format.
> It is hard to understand. :(

The differences described in section 4 of that document sound like
pretty serious divergences from the Dwarf 2 spec.  ARM Dwarf 2 creates
multiple .debug_info sections, one for each source file, with names
suffixed by the source file name.  This affects the way name lookup is
performed:

    This organisation makes the debugger's job in performing name lookup
    more complex. With a single debug table per object it need merely
    identify the place within the single table describing the function
    definition containing the current pc, and work backward and outward
    through the nested scopes described by the table. In the ARM DWARF2
    organisation, it needs to do that first, but then needs to look
    through the tables for files containing the function definition or
    included from those files, and the other debug sections describing
    sections generated from those files. This is possible because:

    - the .debug_line table in the set of tables describing a file
      contains both the name of the file and the names of the files it
      directly includes

    - the .debug_line table in the set of tables describing a code or data
      section contains the name of all files defining entities included in
      the section.

    The order of declarations and definitions can be reconstructed, since
    source position information is present for all definitions and
    declarations, and also the source position of #include directives is
    described in macro information tables.

GDB certainly can't read Dwarf 2 information arranged in this way at
the moment.

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

[Michael Eager]

Jim Blandy wrote:
> "Jang, Jaewoo" <jaewoo.jang@aromasoft.com> writes:
> 
>>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
>>
>>I want to know whether gdb will support ARM dwarf2 format,
>>or it is possible to patch gdb that support ARM dwarf format.
>>Now I try to understand source codes that is part of reading elf format.
>>It is hard to understand. :(
> 
> 
> The differences described in section 4 of that document sound like
> pretty serious divergences from the Dwarf 2 spec.  ARM Dwarf 2 creates
> multiple .debug_info sections, one for each source file, with names
> suffixed by the source file name.  This affects the way name lookup is
> performed:
> 
>     This organisation makes the debugger's job in performing name lookup
>     more complex. With a single debug table per object it need merely
>     identify the place within the single table describing the function
>     definition containing the current pc, and work backward and outward
>     through the nested scopes described by the table. In the ARM DWARF2
>     organisation, it needs to do that first, but then needs to look
>     through the tables for files containing the function definition or
>     included from those files, and the other debug sections describing
>     sections generated from those files. This is possible because:
> 
>     - the .debug_line table in the set of tables describing a file
>       contains both the name of the file and the names of the files it
>       directly includes
> 
>     - the .debug_line table in the set of tables describing a code or data
>       section contains the name of all files defining entities included in
>       the section.
> 
>     The order of declarations and definitions can be reconstructed, since
>     source position information is present for all definitions and
>     declarations, and also the source position of #include directives is
>     described in macro information tables.
> 
> GDB certainly can't read Dwarf 2 information arranged in this way at
> the moment.

It wasn't clear to me from skiming their document that they were
generating multiple .debug_info sections, but now I see that this is
described in terms of generating "table_name$$$file_name", where, I
assume, table_name is .debug_info or other predefined name.

That really does make it a different file format, requiring different
processing.


-- 
Michael Eager	 Eager Consulting     eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

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

[Tim Combs]

When I talked to Arm support about the 1.0.1 they mentioned that the
next compiler would have better GDB support.  It did because they fixed
a few bugs in their DWARF generation.  They recommended going to a
later compiler because their DWARF2 generation is much better.
It is but it has the same design.  It generates a compile unit for
each header file in the file.  This makes referent die support necessary
for the Arm ADS compiler.


Tim
On Fri, Jan 09, 2004 at 09:16:32AM -0800, Michael Eager wrote:
> Jim Blandy wrote:
> > "Jang, Jaewoo" <jaewoo.jang@aromasoft.com> writes:
> > 
> >>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
> >>
> >>I want to know whether gdb will support ARM dwarf2 format,
> >>or it is possible to patch gdb that support ARM dwarf format.
> >>Now I try to understand source codes that is part of reading elf format.
> >>It is hard to understand. :(
> > 
> > 
> > The differences described in section 4 of that document sound like
> > pretty serious divergences from the Dwarf 2 spec.  ARM Dwarf 2 creates
> > multiple .debug_info sections, one for each source file, with names
> > suffixed by the source file name.  This affects the way name lookup is
> > performed:
> > 
> >     This organisation makes the debugger's job in performing name lookup
> >     more complex. With a single debug table per object it need merely
> >     identify the place within the single table describing the function
> >     definition containing the current pc, and work backward and outward
> >     through the nested scopes described by the table. In the ARM DWARF2
> >     organisation, it needs to do that first, but then needs to look
> >     through the tables for files containing the function definition or
> >     included from those files, and the other debug sections describing
> >     sections generated from those files. This is possible because:
> > 
> >     - the .debug_line table in the set of tables describing a file
> >       contains both the name of the file and the names of the files it
> >       directly includes
> > 
> >     - the .debug_line table in the set of tables describing a code or data
> >       section contains the name of all files defining entities included in
> >       the section.
> > 
> >     The order of declarations and definitions can be reconstructed, since
> >     source position information is present for all definitions and
> >     declarations, and also the source position of #include directives is
> >     described in macro information tables.
> > 
> > GDB certainly can't read Dwarf 2 information arranged in this way at
> > the moment.
> 
> It wasn't clear to me from skiming their document that they were
> generating multiple .debug_info sections, but now I see that this is
> described in terms of generating "table_name$$$file_name", where, I
> assume, table_name is .debug_info or other predefined name.
> 
> That really does make it a different file format, requiring different
> processing.
> 
> 
> -- 
> Michael Eager	 Eager Consulting     eager@eagercon.com
> 1960 Park Blvd., Palo Alto, CA 94306  650-325-8077
>