Re: [Libunwind-devel] Problems Compiling for Power

[David Mosberger-Tang]

Remember that libunwind is not just for debuggers.  Local unwinding is
often performance-sensitive (think exception handling, code profiling,
etc.), so it is desirable to have libunwind optimized as much as
possible.  One way to achieve that is to have each libunwind support
one and only one ABI.  You don't see this very much on the
DWARF-unwinder yet, but if you look at the ia64-unwinder, you see that
local unwinding results in highly efficient code (e.g., accessing
memory is just dereferencing a pointer, etc.).

As more DWARF targets are added, it might make sense to restructure
some of the code for increased re-use (both at the source and object
level), but for now, the model is one libunwind per ABI.  Of course,
there is no problem dlopen'ing multiple libunwind objects, so in
practical terms, this solution should work just fine.

Another question of course is whether 32 and 64-bit variants of an ABI
should be considered as related ABIs or as completely different ABIs.
That's a matter of judgment.  x86 and x86-64 are different in ways
other than pointer-size and so it makes sense to me that they should
be treated as separate ABIs.  OTOH, the HP-UX 32-bit and 64-bit ABI
variants for ia64 are close enough that it probably would make sense
to cover them with a single libunwind.  I'm not sure where PPC lies,
so somebody who's more familiar with PPC will have to make that call.

  --david

On 9/4/07, Thiago Jung Bauermann <address@hidden> wrote:
> On Tue, 2007-09-04 at 11:48 -0700, Arun Sharma wrote:
>
> > But you want a single 64 bit debugger to link with two copies of
> > libunwind to
> > debug two different ABIs. Did I state the problem correctly?
>
> It seems more natural to me to have one libunwind which understands the
> two different ABIs, instead of linking with two versions of the same
> library. Isn't it possible to use this approach?
>
> --
> []'s
> Thiago Jung Bauermann
> Software Engineer
> IBM Linux Technology Center
>
>
>
> _______________________________________________
> Libunwind-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/libunwind-devel
>


-- 
Mosberger Consulting LLC, http://www.mosberger-consulting.com/