[Bug threads/16413] New: Single-stepping function accessing TLS causes SIGSEGV of traced process

[Bug threads/16413] New: Single-stepping function accessing TLS causes SIGSEGV of traced process

[gr.sourceware at anguta dot net]

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

            Bug ID: 16413
           Summary: Single-stepping function accessing TLS causes SIGSEGV
                    of traced process
           Product: gdb
           Version: 7.6
            Status: NEW
          Severity: normal
          Priority: P2
         Component: threads
          Assignee: unassigned at sourceware dot org
          Reporter: gr.sourceware at anguta dot net
            Target: x86_64-linux-gnu
             Build: Ubuntu 13.10

Created attachment 7341
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7341&action=edit
Code snippet exhibiting the issue.

Hello,

I've been experiencing this bug for some time with various gdb versions up to
7.6.1 (included): When single-stepping a function accessing a TLS variable in a
PIC binary, the traced process gets a SIGSEGV.

I could reproduce this using a small code snippet, as attached.

Sample session below:

$ gcc -pthread -fPIC -g gdb-tls.c -o gdb-tls -lpthread
$ gdb ./gdb-tls 
GNU gdb (GDB) 7.6.1-ubuntu
Copyright (C) 2013 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-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /tmp/gdb-tls...done.
(gdb) br foo
Breakpoint 1 at 0x4006a3: file gdb-tls.c, line 18.
(gdb) r
Starting program: /tmp/./gdb-tls 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, foo () at gdb-tls.c:18
18              global_tls++;
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
foo () at gdb-tls.c:18
18              global_tls++;
(gdb)

Running this without gdb, or without breakpoints works fine.
Compiling without -fPIC fixes the issue, as well as with clang instead of gcc.

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

[Bug threads/16413] Single-stepping function accessing TLS causes SIGSEGV of traced process

[qiyao at gcc dot gnu.org]

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

Yao Qi <qiyao at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |qiyao at gcc dot gnu.org

--- Comment #1 from Yao Qi <qiyao at gcc dot gnu.org> ---
(In reply to gr.sourceware from comment #0)
> Created attachment 7341 [details]
> Code snippet exhibiting the issue.
> 
> Hello,
> 
> I've been experiencing this bug for some time with various gdb versions up
> to 7.6.1 (included): When single-stepping a function accessing a TLS
> variable in a PIC binary, the traced process gets a SIGSEGV.

Thanks for reporting this bug.

> 
> I could reproduce this using a small code snippet, as attached.
> 
> Sample session below:
> 
> $ gcc -pthread -fPIC -g gdb-tls.c -o gdb-tls -lpthread
> $ gdb ./gdb-tls 
> GNU gdb (GDB) 7.6.1-ubuntu

If you report a GDB bug here, please use GDB released by FSF.  Bugs of distro
GDB should be reported to corresponding distro bugs tracker.

> 
> Running this without gdb, or without breakpoints works fine.
> Compiling without -fPIC fixes the issue, as well as with clang instead of
> gcc.

I can reproduce this error on FSF GDB HEAD.  Looks to me that GDB does
something wrong in skip prologue, and breakpoint is inserted in the wrong
place,

(gdb) disassemble foo
Dump of assembler code for function foo:
   0x00000000004005dc <+0>:    push   %rbp
   0x00000000004005dd <+1>:    mov    %rsp,%rbp
   0x00000000004005e0 <+4>:    push   %rbx
   0x00000000004005e1 <+5>:    mov    %fs:0x0,%rax
   0x00000000004005ea <+14>:    lea    -0x4(%rax),%rax
   0x00000000004005f1 <+21>:    mov    (%rax),%eax
   0x00000000004005f3 <+23>:    lea    0x1(%rax),%ebx
   0x00000000004005f6 <+26>:    mov    %fs:0x0,%rax
   0x00000000004005ff <+35>:    lea    -0x4(%rax),%rax
   0x0000000000400606 <+42>:    mov    %ebx,(%rax)
   0x0000000000400608 <+44>:    pop    %rbx
   0x0000000000400609 <+45>:    pop    %rbp
   0x000000000040060a <+46>:    retq

(gdb) b foo
Breakpoint 1 at 0x4005e2: file pr16413.c, line 18.

0x4005e2 is not the right place to insert breakpoint (in the middle of an
instruction).  GDB replies on line table, from debug information, to decide the
first instruction of the function body.  Let look at the .debug_line section,

$ readelf -wL /scratch/yqi/pr16413
Decoded dump of debug contents of section .debug_line:

CU: pr16413.c:
File name                            Line number    Starting address
pr16413.c                                     17            0x4005dc

pr16413.c                                     18            0x4005e2
                                                            ^^^^^^^^
pr16413.c                                     19            0x400608

The information in .debug_line is wrong, and that is reason GDB inserts
breakpoint on the wrong place (0x4005e2).  This is a GCC bug, but I didn't try
recent GCC.

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