Hi Michael, In the bug-report, you're wondering about the meaning of the unwind directives in the assembly generated by GCC. Those are described in the Itanium Architecture Assembly Language Reference Guide, available here:
http://www.intel.com/cd/software/products/asmo-na/eng/220024.htm As described on page 66, the .mem.offset is unrelated to unwind info (it's just a hint to the assembler so it doesn't issue false warnings). Starting on page 35, the manual describes the unwind directives. As described there, "save.g 0x1" gets translated into a gr_mem unwind descriptor. These descriptors are documented in the Itanium Software Conventions & Runtime Architecture Guide, available here: http://www.intel.com/design/itanium/downloads/245358.htm Looking at that manual, ".save.g 0x1" basically means that register r4 gets spilled/saved during the function's prologue. The save-location is implicit and it appears like there is some disagreement here between libunwind and GCC as to what that location should be (I know there used to be problems in this area, though I thought they had been resolved). Actually, an off-by-8 error sounds a bit like it might be 16-byte-alignment related. Could you perhaps attach the complete assembly output to the test-case? Also, what version of libunwind are you using? Best regards, --david On 11/15/06, Michael Matz <[EMAIL PROTECTED]> wrote:
Hi libunwind :) [I'm not subscribed, please leave me CCed, I tried it already on the HP libunwind list, but that one seems to be dead] I'll try it here in the hope to find someone who knows unwinding on ia64 a bit, of which I unfortunately have not much idea. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29166 has a testcase which breaks with gcc-3.3.3 and -4.1 (and probably others too), because either the unwind information emitted by gcc is wrong, or because libunwind somehow misinterprets it. Anyway, the save locations of r4-r7 are off by 8 and hence those registers will have the wrong content after returning from the call. My knowledge about ia64 unwinding and the assembler pseudo ops is not enough to even determine who is wrong, gcc or libunwind, as you can see in the bugreport :-( I traced libunwind a bit, only to get stuck somewhere in _ULia64_find_save_locs. Could someone give me a push in the right direction? Ciao, Michael. _______________________________________________ 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
