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 <[EMAIL PROTECTED]> 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 > [email protected] > http://lists.nongnu.org/mailman/listinfo/libunwind-devel > -- Mosberger Consulting LLC, http://www.mosberger-consulting.com/ _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
