Well David, I think that this would be very important.
Let's say your are building some kind of debugger (e.g. frysk) using
libunwind. This raises a problem that in a x86_64 system you have
several processes that are only x86, and your debugger would not be able
to unwind this processes, so you would need to use to different compiled
debuggers.
I'm raising this problem because I'm working now in powerpc32 support,
and that's very important because in a ppc64 server several processes
are ppc32, and this will not change for a while, because they are
intentionally 32 bits, in some cases, ppc32 binaries can be faster than
ppc64. So it would be very important to libunwind64 be able to debug
both ppc32 and ppc64, not only libunwind-ppc32 debug ppc32. And ppc32
and ppc54 have different ABIs, but linux for ppc63 is able to deal with
both.
Hi Jose, from your description above, the ppc situation is very similar to x86.
So if we come up with a solution for x86, it should apply to ppc as well.
What do you all think of it?
A unit test (a variant of Gtest-bt.c
?) that shows the problem would be an excellent starting point.
From your description (and from what other frysk folks posted to the list),
it looks like you want to use:
* frysk64 to debug both 32 and 64 bit processes.
Current status is:
* fryst64 linked with libunwind works for 64 bit targets
* frysk64 linked with libunwind-xxx32 works for 32 bit targets
* frysk32 linked with libunwind works for 32 bit targets
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?
I think the patches to make this case work should be broken into:
* patches needed (if any) to link 2 copies of libunwind (each with a different ABI) into a binary
* patches to do cross ABI dwarf unwind info parsing. I expect these patches to help with parsing unwind info for statically linked binaries as well.
Building libunwind twice with two different targets shouldn't be too difficult?
-Arun