Re: [libunwind] dlopen() and libunwind()

[David Mosberger-Tang]

On 9/27/05, Peter Chubb <address@hidden> wrote:
> >>>>> "David" == David Mosberger-Tang <address@hidden> writes:
>
> David> You shouldn't have to do anything.  dlopen() will add the newly
> David> opened library to the list of shared objects such that
> David> dl_iterate_phdr() can find it.  If that doesn't work, something
> David> is broken.
>
> I'm not using dlopen().

Then why mention it in $SUBJECT? ;-)

> I'm trying to debug linux running in a
> virtual machine.  The kernel is loaded `by hand' (using a slightly
> hacked bootloader).  Hence:  I have several ELF files.  I have a memory
> space.  I know the mappings (or can get them from /proc).  I need to
> be able to extract unwind info from the ELF files and give it to
> libunwind.

Libunwind is a generic API and not specific to ELF in any way. 
Internally, libunwind does, of course, use ELF on the platforms where
it is used, but those internal routines are not exposed through the
API (and shouldn't be).  What you should do is use
unw_create_addr_space() with the appropriate call-backs.  Most of the
code you need to implement the call-backs probably already exists
either in libunwind or in libunwind-users (such as gdb).  For example,
see libunwind/src/elfxx.c for a possible (and inefficient)
implementation of the get_proc_name() call-back.  That code is open
source (MIT-like license) so you can feel free to borrow from it as
needed.  Also, note that there is unw_search_ia64_unwind_table(),
which is a helper-routine to search an ia64 unwind-table, which will
help implementing the find_proc_info() call-back.  It may also be
helpful to look at ia64-tdep.c:ia64_find_unwind_table() in gdb.  The
code implementing libunwind-ptrace(3) may also be helpful (in
libunwind/src/ptrace).

Hope this helps,

  --david
--
Mosberger Consulting LLC, voice/fax: 510-744-9372,
http://www.mosberger-consulting.com/
35706 Runckel Lane, Fremont, CA 94536