This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug threads/16413] Single-stepping function accessing TLS causes SIGSEGV of traced process
- From: "qiyao at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Sat, 15 Feb 2014 06:36:12 +0000
- Subject: [Bug threads/16413] Single-stepping function accessing TLS causes SIGSEGV of traced process
- Auto-submitted: auto-generated
- References: <bug-16413-4717 at http dot sourceware dot org/bugzilla/>
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.