Re: Using dwfl to enumerate frames of current thread

From: Ben Gamari <ben at smart-cactus dot org>

To: elfutils-devel at lists dot fedorahosted dot org

Date: Sat, 22 Aug 2015 12:18:46 +0200

Subject: Re: Using dwfl to enumerate frames of current thread

Mark Wielaard <mjw@redhat.com> writes:
> On Fri, Aug 21, 2015 at 06:25:38PM +0200, Ben Gamari wrote:
>> Does elfutils need .debug_ranges as well?
>
> Only if the DWARF producer created DIEs with DW_AT_ranges attributes.
> You seem to never do that. If your range is just one simple one you can
> just use a DW_AT_low_pc/high_pc pair and .debug_ranges will never be
> used.
>
I actually ask because while we don't produce or use the .debug_ranges
section, they sneak into our executables from the C runtime system
objects. However, whatever is emitting it seems to be doing a
questionable job,
$ objdump --dwarf-check -e inplace/lib/bin/ghc-stage2 -x > /dev/null
objdump: Warning: There is an overlap [0x780 - 0x750] in .debug_ranges section.
objdump: Warning: There is an overlap [0x6000 - 0x5fc0] in .debug_ranges section.
objdump: Warning: There is an overlap [0x6860 - 0x6820] in .debug_ranges section.
objdump: Warning: There is an overlap [0x68f0 - 0x68b0] in .debug_ranges section.
objdump: Warning: There is an overlap [0x6980 - 0x6940] in .debug_ranges section.
objdump: Warning: There is an overlap [0x6a10 - 0x69d0] in .debug_ranges section.
objdump: Warning: There is an overlap [0x6aa0 - 0x6a60] in .debug_ranges section.
objdump: Warning: There is an overlap [0x6b30 - 0x6af0] in .debug_ranges section.
objdump: Warning: There is an overlap [0x6bb0 - 0x6b70] in .debug_ranges section.
objdump: Warning: There is an overlap [0x8b40 - 0x8b10] in .debug_ranges section.
objdump: Warning: There is an overlap [0x8bb0 - 0x8b80] in .debug_ranges section.
objdump: Warning: There is an overlap [0x8c20 - 0x8bf0] in .debug_ranges section.
objdump: Warning: There is an overlap [0x8cd0 - 0x8ca0] in .debug_ranges section.
objdump: Warning: There is an overlap [0xa5a0 - 0xa570] in .debug_ranges section.
objdump: Warning: There is an overlap [0xa610 - 0xa5e0] in .debug_ranges section.
objdump: Warning: There is an overlap [0xa680 - 0xa650] in .debug_ranges section.
objdump: Warning: There is an overlap [0xa730 - 0xa700] in .debug_ranges section.
objdump: Warning: There is an overlap [0xba90 - 0xba60] in .debug_ranges section.
objdump: Warning: There is an overlap [0xd430 - 0xd400] in .debug_ranges section.
objdump: Warning: There is an overlap [0xdc90 - 0xdc60] in .debug_ranges section.
I have read that this might simply be due to DWARF 4 produced by GCC,
although this is essentially hearsay.
> Also see Appendix B -- Debug Section Relationships in
> http://dwarfstd.org/doc/DWARF4.pdf for a picture of which and how
> different debug sections might refer to each other.
>
Thanks!
You'll be pleased to know that libdw has worked out quite well. For
instance, with my patch [1] GHC can produce a backtrace like,
0x6ff81f set_initial_registers (rts/Libdw.c:323.0)
0x7fd852eaba68 dwfl_thread_getframes ((null):0.0)
0x7fd852eab4bf (null) ((null):0.0)
0x7fd852eab7f7 dwfl_getthreads ((null):0.0)
0x7fd852eabde3 dwfl_getthread_frames ((null):0.0)
0x6ffbfc libdw_get_backtrace (rts/Libdw.c:295.0)
0x6f187e backtrace_handler (rts/posix/Signals.c:540.0)
0x7fd852b0617f (null) ((null):0.0)
0x407b58 s91t_info (nofib/shootout/n-body/Main.hs:66.27)
0x407cf8 r8YB_info (nofib/shootout/n-body/Main.hs:83.5)
0x408408 s99O_info (nofib/shootout/n-body/Main.hs:28.19)
0x409e80 Main_main1_info (nofib/shootout/n-body/Main.hs:27.26)
0x6f41c0 stg_catch_frame_info (rts/Exception.cmm:370.1)
0x6f29a8 stg_stop_thread_info (rts/StgStartup.cmm:42.1)
There's still a fair amount of work left to integrate this fully, but at
least the tricky DWARF work is done.
Thanks again for your help,
- Ben
[1] https://phabricator.haskell.org/D1156