[Dwarf-Discuss] DW_AT_specification chains

John DelSignore jdelsign@totalviewtech.com
Wed Apr 23 20:25:56 GMT 2008


Legal or not, I have definitely seen specification/declaration chains before. Our debugger used to get upset about that, but now we deal with it OK.  I dug the following out of our bug tracking data base:

------------------------------cut-here------------------------------
In the test tx_namespace_scopes.cxx, with gcc 4.0.0 we have this declaration:

  namespace A {
    int a1;
  };

The dwarf for this creates:

 <1><a67>: Abbrev Number: 2 (DW_TAG_namespace)
     DW_AT_sibling     : <da4>	
     DW_AT_name        : A	
     DW_AT_decl_file   : 1	
     DW_AT_decl_line   : 46	
...
 <2><be5>: Abbrev Number: 7 (DW_TAG_variable)
     DW_AT_name        : a1	
     DW_AT_decl_file   : 1	
     DW_AT_decl_line   : 43	
     DW_AT_MIPS_linkage_name: _ZN1A2a1E	
     DW_AT_type        : <e1d>	
     DW_AT_external    : 1	
     DW_AT_declaration : 1	
...
 <2><c6c>: Abbrev Number: 11 (DW_TAG_variable)
     DW_AT_specification: <be5>	
     DW_AT_declaration : 1
...
 <1><1094>: Abbrev Number: 33 (DW_TAG_variable)
     DW_AT_specification: <c6c>	
     DW_AT_location    : 5 byte block: 3 d8 98 4 8 	(DW_OP_addr: 80498d8; )

Apparently when we see <be5> we are supposed to declare the
variable without a location, as just a declaration. Then when we
see <c6c> we just remember it.  When we see <1094> we are to fill
in the location.
------------------------------cut-here------------------------------

Seems weird to do it this way, but I've seen a lot of weird DWARF. And somebody must have thought this was wrong because GCC 4.0.0 created DIEs like <c6c>, but GCC 4.0.3 did not.

In any case, I think in Marcel's example, what he shows is illegal because DIEs X1 and Y1 are missing DW_AT_declaration attributes set to 1, so the specifications should not be referring back to them.

Cheers, John D.


Michael Eager wrote:
> Marcel Mettes wrote:
>> Hello,
>>
>> I was wondering what the semantics are of a series of DW_AT_specifications
>> that are supposed to form some kind of chain?
>>
>> For example
>>
>>     X1 TAG_variable
>>     X2     DW_AT_name = "x"
>>    
>>     Y1 TAG_variable
>>     Y2     DW_AT_specification = X1
>>     Y3     DW_AT_external = 1
>>     Y4     DW_AT_type = ...
>>
>>
>>     Z1 TAG_variable
>>     Z2     DW_AT_specification = Y1
>>     Z3     DW_AT_location = ...
>>
>> Would this be valid or should the DW_AT_specification at offset Z2
>> point directly to X1?
> 
> Here's what the DWARF Spec says:
> 
>     2.13.2 Declarations Completing Non-Defining Declarations
> 
>     Debugging information entries that represent a declaration that completes
>     another (earlier) non-defining declaration, may have a DW_AT_specification
>     attribute whose value is a reference to the debugging information entry
>     representing the non-defining declaration. Debugging information entries
>     with a DW_AT_specification attribute do not need to duplicate information
>     provided by the debugging information entry referenced by that specification
>     attribute.
> 
> I take this to mean that you can have the following in your program:
> 
>     struct foo;
> 
>     struct foo { int x; };
> 
> Where the second (defining) declaration has an AT_specification which
> points back to the first (non-defining) declaration.
> 
> There are other more complex examples for languages like C++.
> 
> Given the very limited detail in your example, the answer to your
> question about whether this is valid is "it depends".  It would help
> to have the source code which this is supposed to describe, as well
> as other information which would put it in context, say, whether
> this was a single compilation, or where the source appears in
> the program (e.g., within or outside of a function).
> 
> 




More information about the Dwarf-discuss mailing list