libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libunwind-devel] problem with ms_abi on x86-64


From: Ariel Burton
Subject: Re: [Libunwind-devel] problem with ms_abi on x86-64
Date: Tue, 24 May 2011 12:08:38 -0400
User-agent: Mutt/1.4.1i

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, <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]