Thanks for the prompt reply.
Yes, that's what the compiler is doing. Here's the
assembler for the prologue of f_ms_abi:
movdqa %xmm6, -176(%rbp)
movdqa %xmm7, -160(%rbp)
movdqa %xmm8, -144(%rbp)
movdqa %xmm9, -128(%rbp)
movdqa %xmm10, -112(%rbp)
movdqa %xmm11, -96(%rbp)
movdqa %xmm12, -80(%rbp)
movdqa %xmm13, -64(%rbp)
movdqa %xmm14, -48(%rbp)
movdqa %xmm15, -32(%rbp)
and readelf -wif reports this:
DW_CFA_offset: r32 (xmm15) at cfa-48
DW_CFA_offset: r31 (xmm14) at cfa-64
DW_CFA_offset: r30 (xmm13) at cfa-80
DW_CFA_offset: r29 (xmm12) at cfa-96
DW_CFA_offset: r28 (xmm11) at cfa-112
DW_CFA_offset: r27 (xmm10) at cfa-128
DW_CFA_offset: r26 (xmm9) at cfa-144
DW_CFA_offset: r25 (xmm8) at cfa-160
DW_CFA_offset: r24 (xmm7) at cfa-176
DW_CFA_offset: r23 (xmm6) at cfa-192
I think that teaching libunwind about these extra
registers is a good first step.
I played a little with the sources. This change seemed
to do the trick for my case, but it's by no means complete.
Nor do I know enough about libunwind to know if it's correct.
*** libunwind-0.99/include/tdep-x86_64/dwarf-config.h 2011-05-22
18:36:45.286625000 -0400
--- tmp/libunwind-0.99/include/tdep-x86_64/dwarf-config.h 2009-05-08
12:34:10.000000000 -0400
***************
*** 30,42 ****
#ifndef dwarf_config_h
#define dwarf_config_h
/* XXX need to verify if this value is correct */
! #define DWARF_NUM_PRESERVED_REGS 33
! #define DWARF_REGNUM_MAP_LENGTH 25
/* Return TRUE if the ADDR_SPACE uses big-endian byte-order. */
#define dwarf_is_big_endian(addr_space) 0
/* Convert a pointer to a dwarf_cursor structure to a pointer to
--- 30,42 ----
#ifndef dwarf_config_h
#define dwarf_config_h
/* XXX need to verify if this value is correct */
! #define DWARF_NUM_PRESERVED_REGS 17
! #define DWARF_REGNUM_MAP_LENGTH 17
/* Return TRUE if the ADDR_SPACE uses big-endian byte-order. */
#define dwarf_is_big_endian(addr_space) 0
/* Convert a pointer to a dwarf_cursor structure to a pointer to
*** libunwind-0.99/src/x86_64/Gglobal.c 2011-05-23 12:19:22.404294000 -0400
--- tmp/libunwind-0.99/src/x86_64/Gglobal.c 2009-05-08 12:34:10.000000000
-0400
***************
*** 31,41 ****
HIDDEN pthread_mutex_t x86_64_lock = PTHREAD_MUTEX_INITIALIZER;
HIDDEN int tdep_needs_initialization = 1;
/* See comments for svr4_dbx_register_map[] in gcc/config/i386/i386.c. */
! HIDDEN uint8_t dwarf_to_unw_regnum_map[25] =
{
UNW_X86_64_RAX,
UNW_X86_64_RDX,
UNW_X86_64_RCX,
UNW_X86_64_RBX,
--- 31,41 ----
HIDDEN pthread_mutex_t x86_64_lock = PTHREAD_MUTEX_INITIALIZER;
HIDDEN int tdep_needs_initialization = 1;
/* See comments for svr4_dbx_register_map[] in gcc/config/i386/i386.c. */
! HIDDEN uint8_t dwarf_to_unw_regnum_map[17] =
{
UNW_X86_64_RAX,
UNW_X86_64_RDX,
UNW_X86_64_RCX,
UNW_X86_64_RBX,
Ariel
On Tue 24 May 09:45, Arun Sharma wrote:
> On Tue, May 24, 2011 at 8:18 AM, <ariel.bur...@roguewave.com> wrote:
> >
> > Summary
> > =======
> >
> > libunwind is not correctly unwinding through frames for
> > functions annotated with the __attribute__((ms_abi)).
>
> The set of regs known to libunwind on x64 are in
> include/libunwind_x86_64.h (look for x86_64_regnum_t). I'm not very
> familiar with the microsoft calling conventions or gcc's
> interpretation of it.
>
> It looks like gcc is using dwarf regs 23-32 for xmm6-xmm15. If all
> you need to do is teach libunwind about these extra regs numbers in a
> simple patch, we could consider it for the upcoming release. Anything
> more complex is too late in the game.
>
> -Arun
_______________________________________________
Libunwind-devel mailing list
Libunwind-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/libunwind-devel
