[Bug threads/16778] New: amd64 displacement code oddity; segfault

["prumpf at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

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

            Bug ID: 16778
           Summary: amd64 displacement code oddity; segfault
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: threads
          Assignee: unassigned at sourceware dot org
          Reporter: prumpf at gmail dot com

Created attachment 7502
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7502&action=edit
diff

(I'm not sure I've categorized this correctly)

This is a bug report for gdb 7.6.2, built from yesterday's git repository
sources, on amd64 hardware (a Debian system). It affects non-stop mode only.
The displacement code which is activated in non-stop mode appears to truncate
return addresses on the stack, resulting in strange segfaults when debugging
threaded code. I ran into the issue in another context but I believe I have a
test case. It's possible I'm merely confused.

I'm having a very hard time making sense of this bit of code in amd64-tdep.c;

      retaddr = read_memory_unsigned_integer (rsp, retaddr_len, byte_order);
      retaddr = (retaddr - insn_offset) & 0xffffffffUL;
      write_memory_unsigned_integer (rsp, retaddr_len, byte_order, retaddr);

The second line, in particular. It seems to me that it would break debugging
shared libraries, which do not reside in the low 4 GB of virtual memory (on my
machine). Indeed, my experiments seem to confirm that something is wrong:

---------
% gcc -fPIC -g -shared -o libfail.so gdb-fail-library.c
gcc -fPIC -g -shared -o libfail.so gdb-fail-library.c
% gcc -g gdb-fail.c -L . -lfail
gcc -g gdb-fail.c -L . -lfail
% ./gdb-build/gdb/gdb a.out
./gdb-build/gdb/gdb a.out
GNU gdb (GDB) 7.7.50.20140328-cvs
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-unknown-linux-gnu".
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 a.out...done.
(gdb) set non-stop on
set non-stop on
(gdb) b f
b f
Breakpoint 1 at 0x400540
(gdb) r
r
Starting program: .../a.out
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?

Breakpoint 1, f () at gdb-fail-library.c:6
6      return g();
(gdb) stepi
stepi
0x00007ffff7bdc580 in g@plt () from .../libfail.so
(gdb) bt
bt
#0  0x00007ffff7bdc580 in g@plt () from .../libfail.so
#1  0x00000000f7bdc699 in ?? ()
#2  0x00007fffffffea00 in ?? ()
#3  0x0000000000400666 in main () at gdb-fail.c:5
Backtrace stopped: frame did not save the PC
---------

Note the truncated return address on the stack. And indeed:

----------
(gdb) c
c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x00000000f7bdc699 in ?? ()
----------

The test program/library is fairly minimal:
---------
int g(void) {
  return 0;
}

int f(void) {
  return g();
}
---------
extern int f(void);

int main(void)
{
  f();

  return 0;
}
---------

I very much suspect there is a good reason the original code did not omit the
&0xffffffffUL part, but removing it appears to work in this one test case. I've
attached a patch that does that.

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