Arun,
We have multi-platform, or remote, unwinding working. For instance,
x86-64 backtracing an i386, or even a 32-bit PowerPC unwinding an
x86-64. That is cool, way cool, something to celebrate! We've finally
got this out of the "left as an exercise for the reader" bucket :-)
With this functionality working becomes possible to do cool stuff such
as display backtraces of a process as it alternatively exec's 32-bit and
then 64-bit programs.
Our challenges now are:
- get frysk's existing local fixes to libunwind finally merged
- work through the new issues identified in getting multi-platform
unwinding working
Nurdin,
Looking at Gget_unwind_table.c. I see the goal is to re-use
dwarf_read_encoded_pointer code - we certainly do not want to reproduce
the logic found within that. Looking at the call, I see:
dwarf_read_encoded_pointer (temp_local_addr_space, &temp_local_accessors,
&addr, hdr->eh_frame_ptr_enc, pi,
&eh_frame_start, NULL)) < 0)
what about instead of passing absolute addresses; pass offsets, and for the
accessor data parameter, supply the base address vis:
dwarf_read_encoded_pointer (temp_local_addr_space, &temp_local_accessors,
0, hdr->eh_frame_ptr_enc, pi,
((char*)&eh_frame_start - (char*)addr,
&addr)) < 0)
and have the memory accessors do the offsetting. Would that eliminate
the need to map things into the first 64k (oops 32-bit).
That way, while there is still a 32-bit size limitation, the data can be
located anywhere within the address space.
Obviously though, a more ideal solution would be to clean up the code so
that it could better handle 32/64 addresses.
Andrew
Is it a hard requirement that a x86_64 frysk is able to unwind an i386
process? If you're ok with doing this in a separate (i386) address
space, you can use the i386 native version of libunwind, without any
code changes.
If you must do this in a x86_64 address space, I would suggest
treating i386 the same way you'd treat ppc32 i.e by not using ptrace
related code and using your own accessors.
-Arun
------------------------------------------------------------------------
_______________________________________________
Libunwind-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/libunwind-devel
_______________________________________________
Libunwind-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/libunwind-devel
