[Dwarf-discuss] Suggestion of FAQ entries

[David Anderson]

I'm asking (hereby) that new FAQ entries be created.

I'm posting this to the dwarf-discuss list so that
others can suggest better wording or correct any mistakes here.
I'm suggesting these because, for the first two, it
was brought up on a list as confusing folks, and
for the last (DW_FORM_ref_addr) at least one compiler
producer has (2005) used the bogus DWARF2 version for this.

A compiler producer has violated (in 2005)
the rule mentioned in the first FAQ entry proposed here.
(I'm not quite sure who the compiler producer is, I was given
compiled objects by someone I don't have explicit
permission to name here -- nobody in the DWARF list,
I believe.)


FAQ entry suggestions for Michael Eager to put on the
dwarf.freestandards.org FAQ:



------------------------------------------------------------
How many DW_TAG_compile_unit entries per Compilation Unit Header?

Each Compilation Unit Header should be followed by exactly one
DW_TAG_compile_unit or one DW_TAG_partial_unit, and the
children of the DW_TAG_compile_unit or DW_TAG_partial_unit
contain Debugging Information Entries for the unit.
A DW_TAG_compile_unit or one DW_TAG_partial_unit has
no sibling entries.



------------------------------------------------------------
Why doesn't the line table 'basic block' register have a reset operation?

It doesn't need one.  
The table  idea is based around creating row entries, conceptually
a row entry for every pc value in the executable text.
All the booleans in the line table, such
as is_stmt, basic_block, end_sequence, prologue_end, and 
epilogue_begin are reset by the creation of a new table_row
(see the individual opcodes that create table rows to see this).
Each row in the line table is defined by a sequence of one or more
line table opcodes and the opcodes precisely define
the value of every column of every row. 



------------------------------------------------------------
How big is a DW_FORM_ref_addr?

In DWARF3, DW_FORM_ref_addr is clearly defined as being 
an offset into the .debug_info section so the reference value
is the size of an offset. In DWARF2 DW_FORM_ref_addr
was (confusingly) defined as being the size of an address
on the target machine.  The DWARF2 definition never made
any sense and was a mistake in the DWARF2 specification:
the field DW_FORM_ref_addr defines is an offset, not an address.
Whether producing DWARF2 or DWARF3, please use the DWARF3
definition of DW_FORM_ref_addr.  


-------------------
David Anderson