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

["qiyao at gcc dot gnu.org" <sourceware-bugzilla@sourceware.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.