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

[Tim Combs <tcombs at urbana dot css dot mot dot com>]

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
>