[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libunwind-devel] Multi-platform unwinding i386 binary on x86_64 bug

From: Andrew Cagney
Subject: Re: [Libunwind-devel] Multi-platform unwinding i386 binary on x86_64 bugs and patch.
Date: Wed, 02 May 2007 17:24:31 -0400
User-agent: Thunderbird (X11/20070301)


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


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.


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.



Libunwind-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]