From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24809 invoked by alias); 11 Jul 2007 06:18:40 -0000 Received: (qmail 24800 invoked by uid 22791); 11 Jul 2007 06:18:40 -0000 X-Spam-Check-By: sourceware.org Received: from topsns2.toshiba-tops.co.jp (HELO topsns2.toshiba-tops.co.jp) (202.230.225.126) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 11 Jul 2007 06:18:32 +0000 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for sourceware.org [209.132.176.174]) with ESMTP; Wed, 11 Jul 2007 15:18:31 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id E621F41F28; Wed, 11 Jul 2007 15:18:20 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id D30DA41EA3; Wed, 11 Jul 2007 15:18:20 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id l6B6IKAF005591; Wed, 11 Jul 2007 15:18:20 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Wed, 11 Jul 2007 06:18:00 -0000 Message-Id: <20070711.151820.55513191.nemoto@toshiba-tops.co.jp> To: gdb@sourceware.org Subject: How to avoid stepping inside libpthread From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 5.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_Jul_11_15_18_20_2007_726)--" Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-07/txt/msg00088.txt.bz2 ----Next_Part(Wed_Jul_11_15_18_20_2007_726)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-length: 2999 When I keep typing "next" command in debug session, gdb might try to do single stepping inside libpthread. And on atomic operations (LL/SC loop, as I'm using Linux/MIPS), the single stepping never ends. GNU gdb 6.6 ... This GDB was configured as "mips-linux"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) b func # thread's entry point Breakpoint 1 at 0x400700: file foo.c, line 6. (gdb) run Starting program: ./foo [Thread debugging using libthread_db enabled] [New Thread 715939536 (LWP 756)] [New Thread 726549712 (LWP 759)] [Switching to Thread 726549712 (LWP 759)] Breakpoint 1, func (arg=0x0) at foo.c:6 6 return arg; /* last statement of the thread */ (gdb) n 7 } (gdb) 0x2ab0ae88 in start_thread () from /lib/libpthread.so.0 (gdb) Single stepping until exit from function start_thread, which has no line number information. The gdb stops. There is a LL/SC loop (atomic_decrement_and_test(&__nptl_nthreads)) after the 0x2ab0ae88 in start_thread(), so it is not wonder the single stepping never ends (SC always fail due to a breakpoint exception). Are there any way to avoid falling into such situations? Only I can do is be careful to not enter "next" command inside libpthread? Once I fell into this situation, C-c can might stop the gdb, but sometimes it cause internal-error. ../../gdb-6.6/gdb/linux-nat.c:1333: internal-error: wait_lwp: Assertion `lp->status == 0' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) I have not investigated this error further. And current gdb snapshot (6.6.50.20070711) behaves differently. GNU gdb 6.6.50.20070711 ... This GDB was configured as "mips-linux"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) b func Breakpoint 1 at 0x400700: file foo.c, line 6. (gdb) run Starting program: ./foo warning: Can not parse XML target description; XML support was disabled at compile time [New LWP 754] [Switching to LWP 754] Breakpoint 1, func (arg=0x0) at foo.c:6 6 return arg; /* last statement of the thread */ (gdb) 7 } (gdb) warning: GDB can't find the start of the function at 0x2ab0ae88. GDB is unable to find the start of the function at 0x2ab0ae88 and thus can't determine the size of that function's stack frame. This means that GDB may be unable to access that stack frame, or the frames below it. This problem is most likely caused by an invalid program counter or stack pointer. However, if you think GDB should simply search farther back from 0x2ab0ae88 for code which looks like the beginning of a function, you can increase the range of the search using the `set heuristic-fence-post' command. warning: GDB can't find the start of the function at 0x2ab0ae87. 0x2ab0ae88 in ?? () (gdb) n Cannot find bounds of current function It seems current gdb snapshot can not find symbol for 0x2ab0ae88. Is this behavior intentional? --- Atsushi Nemoto ----Next_Part(Wed_Jul_11_15_18_20_2007_726)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="foo.c" Content-length: 228 #include #include void *func(void *arg) { return arg; } int main(int argc, char **argv) { pthread_t id; pthread_create(&id, NULL, func, NULL); pthread_join(id, NULL); printf("done\n"); return 0; } ----Next_Part(Wed_Jul_11_15_18_20_2007_726)----