Re: [Libunwind-devel] Multi-platform unwinding i386 binary on x86_64 bugs and patch.

[Andrew Cagney]

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
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/libunwind-devel
>