Mark Wielaard wrote: > Which other unwinders are out there, that might rely on the current > numbering?
Well, runtime unwinders using .eh_frame should be fine, since this uses (and has always used) consistently the GCC numbering. I don't know if there are other unwinders using .dwarf_frame ... > The Systemtap runtime unwinder (*) currently is incomplete > (and in one case wrong since the numbering overlaps), so it doesn't > really matter much which solution you pick (we will just have to watch > out and fix things to be as consistent as possible when your change goes > through). If you do change the numbering it would be ideal if there was > a way to detect which one was in place (although it is probably hopeless > because depending on which GCC version is in use there can already be > different numberings). The change will most likely be to consistently use GCC numbering in .dwarf_frame as well, which changes only the encoding of the condition code register. Since you're not using that at all in systemtap, you shouldn't be affected. > BTW. The reason the systemtap runtime unwinder is > a little wrong here is because on all other architectures we assume > eh_frame and debug_frame DWARF register numberings are equal, is ppc > really the only architecture for which that isn't true, or were we just > lucky? As far as Linux goes, yes, ppc was the only architecture with a different encoding between .eh_frame and .dwarf_frame. The only other such platforms I'm aware of are Darwin on 32-bit i386, and some other operating systems on ppc (AIX, Darwin, BSD). Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
