Hey Mark,

thanks a lot for your input and explanations.

On Freitag, 10. Juni 2016 13:04:14 CEST Mark Wielaard wrote:

<snip>

> > How should the obligatory callbacks of Dwfl_Thread_Callbacks be
> > implemented?> 
> >   * next_thread: I'm only interested in the current thread, so doing
> >   something> 
> > similar to perf should be possible here
> > 
> >   * memory_read: just cast the address to a pointer and dereference it?
> >   * set_initial_registers: no clue, really
> 
> This is the big issue. And we don't yet have a standard callback for
> that. Ben Gamari (added to CC) has been working on that. You can find
> his patches at https://github.com/bgamari/elfutils/commits/local-unwind
> with some discussion in the archives:
> https://lists.fedorahosted.org/archives/list/elfutils-devel@lists.fedorahost
> ed.org/thread/VDZY5DA6QEYYXLR4NWUY77NHE43HBSKH/
> https://lists.fedorahosted.org/archives/list/elfutils-devel@lists.fedorahos
> ted.org/thread/VFTKJQ3LS4WN3RVMZES3BOPTHR5IPHU6/
> > Is there an easy-to-grasp example out there somewhere for me to follow on
> > how to use libdw(fl) for in-process stack unwinding?
> 
> Hope the above helps. But feel free to ask more questions.

It does help in the sense that I'll try Ben's patches when I get the time, or 
wait until they get upstreamed before I investigate more.

Ben, have you compared the functionality of libdw in your current patched form 
to libunwind, for process-local unwinding? If not, could you do that? I'd 
mostly be interested in some performance aspects.

Libunwind relies on dl_iterate_phdr, which can add significant overhead when 
unwinding separate threads as it induces synchronization. I hope that with 
explicitly using dwfl_report_elf I could have libdw cache everything that's 
required and only need to update the data when dlopen/dlclose are called.

Cheers

-- 
Milian Wolff
mail@milianw.de
http://milianw.de