From eager@eagerm.com  Fri Mar  2 19:00:32 2012
From: eager@eagerm.com (Michael Eager)
Date: Fri, 02 Mar 2012 11:00:32 -0800
Subject: [Dwarf-Discuss] Query about DWARF output for recursively nested
	inlined subroutines
In-Reply-To: <a8981556839563b263f89f08b7836e60.squirrel@mail.picochip.co.uk>
References: <a8981556839563b263f89f08b7836e60.squirrel@mail.picochip.co.uk>
Message-ID: <4F5118D0.5070908@eagerm.com>

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



From maillist-dwarf@barfooze.de  Fri Mar  2 23:32:35 2012
From: maillist-dwarf@barfooze.de (John Spencer)
Date: Sat, 03 Mar 2012 00:32:35 +0100
Subject: [Dwarf-Discuss] [PATCH] fix libdwarf build on x86_64
Message-ID: <4F515893.2090805@barfooze.de>

the attached patch fixes a build error on amd64.
the previous code was wrongly casting a pointer to int.

--JS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-fix-invalid-casts-on-x64-arch.patch
Type: text/x-patch
Size: 2675 bytes
Desc: not available
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20120303/21d3d6fb/attachment.bin>


