[Dwarf-Discuss] DW_TAG_formal_parameter question
Stoyan Shopov
stoyan.shopov@gmail.com
Mon Jun 8 05:56:28 GMT 2009
Ok, here is a somewhat minimalistic code sample exhibiting the problem:
---------------------- C code --------------------------------------
int func1(void);
int func2(void) { return 0; }
int (*func_ptr)(void) = func2;
int main(void)
{
return func1();
}
int fib(int n)
{
int res;
if (n < 2)
res = n;
else
res = fib(n - 1) + fib(n - 2);
return res;
}
static int inline inline_test(int x)
{
return x++;
}
int func1(void)
{
return func_ptr() + inline_test((int)func1);
}
---------------------- C code end --------------------------------------
---------------------- Makefile --------------------------------------
CC = gcc-4.3.2
CFLAGS = -nostdlib -g -O2 -finline-functions
test.elf: test_0.c
$(CC) $(CFLAGS) -o $@ test_0.c
---------------------- Makefile end --------------------------------------
This is the strange dwarfdump excerpt:
-----------------------------------------------------------------
<1>< 96> DW_TAG_subprogram
DW_AT_sibling <122>
DW_AT_external yes(1)
DW_AT_name func1
DW_AT_decl_file 1
/home/shopov/src/dwdemo/test_0.c
DW_AT_decl_line 28
DW_AT_prototyped yes(1)
DW_AT_type <64>
DW_AT_inline DW_INL_inlined
<2>< 114> DW_TAG_lexical_block
<3>< 115> DW_TAG_formal_parameter
DW_AT_abstract_origin <54>
-----------------------------------------------------------------
I think it is strange for a formal parameter to be a descendant of a lexical
block die. Also, the func1() subprogram seems to be, what is termed in the
dwarf standard, "an abstract instance root" - it should not have any
descendant nodes which have a DW_AT_abstract_origin attribute, as this
attribute should be present only in concrete instance trees, right? Then
again, it is quite possible that there are misunderstandings on my side, and
any clarifications are welcome.
This also seems strange:
---------------------------------------------
<1>< 180> DW_TAG_subprogram
DW_AT_sibling <228>
DW_AT_external yes(1)
DW_AT_name fib
DW_AT_decl_file 1
/home/shopov/src/dwdemo/test_0.c
DW_AT_decl_line 13
DW_AT_prototyped yes(1)
DW_AT_type <64>
DW_AT_inline DW_INL_inlined
<2>< 198> DW_TAG_formal_parameter
DW_AT_name n
DW_AT_decl_file 1
/home/shopov/src/dwdemo/test_0.c
DW_AT_decl_line 12
DW_AT_type <64>
<2>< 207> DW_TAG_variable
DW_AT_name res
DW_AT_decl_file 1
/home/shopov/src/dwdemo/test_0.c
DW_AT_decl_line 14
DW_AT_type <64>
<2>< 218> DW_TAG_lexical_block
<3>< 219> DW_TAG_lexical_block
<4>< 220> DW_TAG_variable
DW_AT_abstract_origin <207>
---------------------------------------------
There are (maybe redundant but not incorrect?) empty lexical blocks, and
also the entry DW_AT_abstract_origin pointing upwards to a node in the same
abstract instance tree (if I understand things correctly).
Earlier I wrote that the problem does not occur with gcc-4.1.2, but this is
not the case - I just tested it again, and the problem occurs there too.
I know this is not a gcc specific list, but I hope there are people
following this list that are also concerned with gcc development and will
instruct me where to redirect these messages, if there is at all anything
wrong and it is not just a misunderstanding of mine.
Thanks,
Stoyan Shopov
2009/6/5 Michael Eager <eager at eagercon.com>
> Just post the one function which corresponds to the DWARF data, along
> with a dump of the corresponding DWARF for this function. Since there
> is an inlined function involved, also post the DWARF for that function.
>
> Stoyan Shopov wrote:
>
>> 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 <mailto: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 <mailto:eager at eagercon.com>
>> 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
>>
>>
>>
>
> --
> 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/20090608/fea2be86/attachment.htm>
More information about the Dwarf-discuss
mailing list