[Bug backtrace/17445] New: 64bit amd64 windows dwarf backtrace corrupt

["muller at ics dot u-strasbg.fr" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17445

            Bug ID: 17445
           Summary: 64bit amd64 windows dwarf backtrace corrupt
           Product: gdb
           Version: unknown
            Status: NEW
          Severity: normal
          Priority: P2
         Component: backtrace
          Assignee: unassigned at sourceware dot org
          Reporter: muller at ics dot u-strasbg.fr

Some time ago, I submitted a problem
concerning dwarf encoding for x86_64-w64-mingw32 or x86_64-pc-cygwin
targets.
https://sourceware.org/ml/binutils/2013-12/msg00232.html
releated to this original thread
https://sourceware.org/ml/binutils/2011-01/msg00323.html


  I now found a case where this issue causes
a loss of the ability to unwind the stack correctly.




$ cat xmm15-problem.c
>>>>>>>>>>>>>>>>>>>>>>>>>>>>Start of source file
#include <math.h>

double
test_xmm14 (double t)
{
  register double x asm ("xmm11");
  register double y asm ("xmm12");
  register double z asm ("xmm14");

  x = 6.7 * t;
  y = 45.234 + t;
  z = y * t + 5.6 * x;
  return z;
}

double
test_xmm15 (double t)
{
  register double x asm ("xmm11");
  register double y asm ("xmm12");
  register double z asm ("xmm15");

  x = 6.7 * t;
  y = 45.234 + t;
  z = y * t + 5.6 * x;
  return z;
}

int
main ()
{
  register double z asm ("xmm15");

  z = 56.8;
  z = test_xmm14 (z);
  z = test_xmm15 (z);
  return 0;
}
>>>>>>>>>>>>>>>>>>>>>>>>>>>>End of source file

Compile with either 

  The result is:
x86_64-w64-mingw32-gcc (GCC) 4.8.3
or native cygwin64:
gcc (GCC) 4.8.3
and try to debug using 7.8 cygwin64 version
(
$ gdb ./xmm15-problem.exe
GNU gdb (GDB) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./xmm15-problem.exe...done.
(gdb) rb test_xmm
Breakpoint 1 at 0x1004010f1: file xmm15-problem.c, line 10.
double test_xmm14(double);
Breakpoint 2 at 0x10040118e: file xmm15-problem.c, line 23.
double test_xmm15(double);
(gdb) r
Starting program: /home/Pierre/test/xmm15-problem.exe
[New Thread 4536.0x9e4]
[New Thread 4536.0x728]

Breakpoint 1, test_xmm14 (t=56.799999999999997) at xmm15-problem.c:10
10        x = 6.7 * t;
(gdb) bt
#0  test_xmm14 (t=56.799999999999997) at xmm15-problem.c:10
#1  0x000000010040123d in main () at xmm15-problem.c:35
(gdb) c
Continuing.

Breakpoint 2, test_xmm15 (t=7926.6671999999999) at xmm15-problem.c:23
23        x = 6.7 * t;
(gdb) bt
#0  test_xmm15 (t=7926.6671999999999) at xmm15-problem.c:23
#1  0x40bef6aacd9e83e4 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) x /gx &t
0x22aa60:       0x40bef6aacd9e83e4
(gdb) inf frame
Stack level 0, frame at 0x22aa60:
 rip = 0x10040118e in test_xmm15 (xmm15-problem.c:23);
    saved rip = 0x40bef6aacd9e83e4
 called by frame at 0x0
 source language c.
 Arglist at 0x22aa18, args: t=7926.6671999999999
 Locals at 0x22aa18, Previous frame's sp is 0x22aa60
 Saved registers:
  rbp at 0x22aa50, rip at 0x22aa40, xmm11 at 0x22aa20, xmm12 at 0x22aa30,
  xmm15 at 0x22aa40
(gdb)

The problem really is that the unwind information about xmm15 register
gets transfered both to xmm15 and to rip (as can be seen by the fact
that both registers are saved in the same stack memory.

  I believe that the solution to this problem needs a change 
in the way dwarf CFI data is handled (both in binutils/dwarf.c 
andd gdb/dwarf2-frame.c).

  The reason of the change from 16 to 32 for the return address register
in the CFI structure is related (see answers from Kzi Tietz to 
the email on binutils mailing list above) is dictated
by the fact that the current code assumes that the "return address register"
which is really only a column in the array of handled registers in the unwind
information, must, in binutils/gdb code be the highest index of that array.

  I did not find anything inside dwarf-4 documentation that mandates this,
and I suspect that this limitation should be lifted.

-- 
You are receiving this mail because:
You are on the CC list for the bug.