bug-gdb
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ARM compiler generates DW_FORM_indirect


From: Jim Blandy
Subject: Re: ARM compiler generates DW_FORM_indirect
Date: 10 Nov 2000 16:22:44 -0500

> Using gdb5.0, I was debugging a little test problem.  The ARM
> C compiler generates by default DWARF2.  When I tried to load it,
> gdb said DW_FORM_indirect wasn't implemented yet.  I am working 
> on implementing it but being a newbie to this part of gdb, I have
> a couple of general questions. The spec says that "the attribute value 
> itself in the .debug_info section begins with an unsigned LEB128 number 
> that represents its form."
> My understanding of the spec is that the .dwarf_info section looks
> like this:
> 1. length of compilation unit
> 2. Version of DWARF info
> 3. offset to .debug_abbrev section
> 4. size of address
> 5. (Some number of) DIEs
>    a. LEB128 number containing abbrev code
>    b. Attribute values
> 
> So I think my confusion is from the gdb code. It seems from my
> untrained eye that I have already read past the attribute value when
> I discover the DW_FORM_indirect.  What is the relationship between
> the attr->value and attr->form and the attr value?

Each DIE in .debug_info starts out with an abbreviation number, which
is an index into the abbreviation table in .debug_abbrev.  The
abbreviation entry selected by that index is a series of (attribute,
form) pairs, terminated by a (0, 0) pair.  This series describes the
contents and layout of the DIE --- what comes after the abbreviation
code in .debug_info.

So, essentially, each DIE starts with a "type" (the abbrev number),
followed by data laid out as specified by that type.  The Dwarf
authors noticed that compilers tended to produce a lot of DIE's with
identical series of attributes, in the same forms, so they decided to
factor out the structural info into the abbrev table, so DIE's could
share it.  I'm told this made Dwarf 2 a lot denser than Dwarf 1.

But if the abbrev table says that some attribute's form is
DW_FORM_indirect, then that means that the form is specified in the
actual DIE data in .debug_info, not as part of the abbrev entry in
.debug_abbrev.  The data data will contain an unsigned LEB128 number
giving the form, followed by data in that form.  DW_FORM_indirect is
just a way to create abbrevs that the form of certain attributes to
vary from one DIE to the next.

So, to parse a DIE:
- Read an abbrev number from .debug_info.
- Look up the abbrev in the abbrev table in .debug_abbrev
- For each (ATTR, FORM) pair in the abbrev's list:
  - If FORM is DW_FORM_indirect:
    - Read another form number FORM2 from .debug_info.
    - Read a FORM2 value from .debug_info.
  - Otherwise, read a FORM value from .debug_info.
  - In either case, that's ATTR's value.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]