From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10393 invoked by alias); 15 Feb 2014 06:36:15 -0000 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org Received: (qmail 10324 invoked by uid 48); 15 Feb 2014 06:36:14 -0000 From: "qiyao at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug threads/16413] Single-stepping function accessing TLS causes SIGSEGV of traced process Date: Sat, 15 Feb 2014 06:36:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: threads X-Bugzilla-Version: 7.6 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: qiyao at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-q1/txt/msg00207.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=16413 Yao Qi changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |qiyao at gcc dot gnu.org --- Comment #1 from Yao Qi --- (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.