[Dwarf-Discuss] DW_TAG_formal_parameter question

Stoyan Shopov stoyan.shopov@gmail.com
Fri Jun 5 19:55:07 GMT 2009


Thank you for your interest and help, Mr Eager, I tried hard for some 40
minutes to minimize the data to exhibit the problem - without success. I
shall now attach to this message the whole directory listing that I have
seen the problem stem from. The problematic elf has been generated by  GNU C
4.3.2 - targeting ARM - yet the same happens with gcc 4.3.2 targeting x86;
the problem * DOES NOT OCCUR * with gcc 4.1.2 for x86. I am sorry to admit
that I am too exhausted right now to proceed with experiments and
investigations - it has been a long day here - in Sofia, Bulgaria - today,
it is probably a better idea for you to simply ignore this message
altogether, and see if I manage to produce a more concise and saner dump in
this week end. Just some food for thought, though - I just noticed that
there are even more peculiar artifacts in the dump - e.g. empty lexical
blocks containing empty lexical blocks. The latest x86 dwarfdump output
should be in the archive for you to inspect, hopefully the Makefile shall
serve well to reproduce the whole affair.

Once again, thank you, Mr Eager


2009/6/5 Michael Eager <eager at eagercon.com>

> Stoyan Shopov wrote:
>
>> Hello,
>>
>> Lately, I have been doing some investigations of gcc dwarf debug
>> information generation, and today I managed to obtain the following
>> dwarfdump output for a gcc compiled object executable (excerpt):
>>
>>
>> ----------------------------------------------------------------------------
>> <1><  122>      DW_TAG_subprogram
>>                DW_AT_external              yes(1)
>>                DW_AT_name                  func1
>>                DW_AT_decl_file             1
>> /home/shopov/src/gear-201108/engine/target_test/test_0.c
>>                DW_AT_decl_line             79
>>                DW_AT_prototyped            yes(1)
>>                DW_AT_type                  <74>
>>                DW_AT_inline                DW_INL_inlined
>>                DW_AT_sibling               <148>
>> <2><  140>      DW_TAG_lexical_block
>> <3><  141>      DW_TAG_formal_parameter
>>                DW_AT_abstract_origin       <98>
>>
>> ----------------------------------------------------------------------------
>>
>> I know this list is not gcc specific, I just want to ask - is this normal
>> - a formal parameter to be a child of (an empty) lexical block? I guess not,
>> but I also could not find anything about that in the dwarf standard, and
>> dwarfdump -ka does not report anything wrong in this respect.
>>
>
> Can you post the source which corresponds to this DWARF data?
> Also, is the DWARF listing complete?  Formal parameters generally
> have names.
>
> --
> Michael Eager    eager at eagercon.com
> 1960 Park Blvd., Palo Alto, CA 94306  650-325-8077
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20090605/d65589c1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dwdemo.tar.bz2
Type: application/x-bzip2
Size: 7145 bytes
Desc: not available
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20090605/d65589c1/attachment.bin>



More information about the Dwarf-discuss mailing list