[Dwarf-Discuss] Query about DWARF output for recursively nested inlined subroutines

[Michael Eager]

On 03/02/2012 02:49 AM, Dan Towner wrote:
> Hi all,
>
> I have noticed the following construct appearing in some DWARF output and
> I'm don't understand what it means, or whether it is actually a bug:
>
>          .uleb128 0x1c   ;# (DIE (0x80a) DW_TAG_inlined_subroutine)
>          .long 0x635        ;# DW_AT_abstract_origin
>          .word _picoMark_LBB23      ;# DW_AT_low_pc
>          .word _picoMark_LBE23      ;# DW_AT_high_pc
>          .byte 0x1   ;# DW_AT_call_file
> (/home/dant/Tools/Verification/Flow/standalone_fn_error.vhd)
>          .byte 0xaf  ;# DW_AT_call_line
>          .uleb128 0x17   ;# (DIE (0x815) DW_TAG_formal_parameter)
>          .long 0x650        ;# DW_AT_abstract_origin
>          .long _picoMark_LLST15     ;# DW_AT_location
>          .uleb128 0x1c   ;# (DIE (0x81e) DW_TAG_inlined_subroutine)
>          .long 0x635        ;# DW_AT_abstract_origin
>          .word _picoMark_LBB25      ;# DW_AT_low_pc
>          .word _picoMark_LBE25      ;# DW_AT_high_pc
>          .byte 0x1   ;# DW_AT_call_file
> (/home/dant/Tools/Verification/Flow/standalone_fn_error.vhd)
>          .byte 0x47  ;# DW_AT_call_line
>          .uleb128 0x17   ;# (DIE (0x829) DW_TAG_formal_parameter)
>          .long 0x650        ;# DW_AT_abstract_origin
>          .long _picoMark_LLST16     ;# DW_AT_location
>          .uleb128 0x1e   ;# (DIE (0x832) DW_TAG_lexical_block)
>          .word _picoMark_LBB26      ;# DW_AT_low_pc
>          .word _picoMark_LBE26      ;# DW_AT_high_pc
>
> There are two puzzling things about this little fragment. Firstly the
> inlined subroutine contains another inline instance of the same subroutine
> within itself (i.e., the first inlined subroutine has abstract origin
> 0x635, and it contains another inlined subroutine child with the same
> abstract origin). This seems to imply that the subroutine is recursive,
> which it isn't. Nowhere in the source code does the subroutine call
> itself.
 >
> Secondly, the DWARF contains call site information for the two
> subroutines, but the second one is simply wrong. The source line for the
> supposed call site (0x47 above) is the first line of the definition of
> `main', and isn't even a call site.
>
> I can supply a test case (for the picochip port) if necessary, but I just
> wanted to get an idea of whether this really is a problem, or I'm just
> misinterpreting what is going on.

It's a bit difficult to tell what is going on.

Can you post a small program which creates output like this,
along with output from readelf -w or dwarfdump?

-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077