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

[Michael Eager <eager at eagercon dot com>]

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