From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19977 invoked by alias); 27 Jun 2005 21:27:11 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 19961 invoked by uid 22791); 27 Jun 2005 21:27:07 -0000 Received: from faui03.informatik.uni-erlangen.de (HELO faui03.informatik.uni-erlangen.de) (131.188.30.103) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 27 Jun 2005 21:27:07 +0000 Received: from faui03.informatik.uni-erlangen.de (faui03.informatik.uni-erlangen.de [131.188.30.103]) by faui03.informatik.uni-erlangen.de (8.12.9/8.12.9) with ESMTP id j5RLR4S8021229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Jun 2005 21:27:04 GMT Received: (from sithglan@localhost) by faui03.informatik.uni-erlangen.de (8.12.9/8.12.9) id j5RLR4YT021228 for gdb@sources.redhat.com; Mon, 27 Jun 2005 23:27:04 +0200 (CEST) Date: Mon, 27 Jun 2005 21:27:00 -0000 From: Thomas Glanzmann To: gdb@sources.redhat.com Subject: gdb eats 100% cpu for relative long time when I single step one instruction Message-ID: <20050627212704.GD8659@cip.informatik.uni-erlangen.de> Mail-Followup-To: Thomas Glanzmann , gdb@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-SW-Source: 2005-06/txt/msg00266.txt.bz2 Hello, I tried to debug an opera binary without debugging information and did the following: gdb ./opera b *0x0838FF00 layout asm layout regs run 2> /dev/null When I hit the breakpoint gdb starts eating my CPU. I have Athlon XP 1700 running Linux 2.6 Debian Sarge. After I get the gdb prompt back I type ni to singlestep to 'push %ebp' which takes a few seconds. I started top and saw that gdb eats my cpu. My X is nearly freezed and I also have trouble to change windows between windows in remote and local screen sessions. Whatever my guess is that gdb does some data analyzing it takes very long because the binary is compiled without debugging information. Is there a switch that I can turn this off or how can I check what gdb does while it blocks my machine during the single step? This happens *only* when I call 'layout asm' gdb thinks that I am in the function jzero_far which is at 0x81cd12a but I am actually in a funtion without a debugging symbol at 0x838fdcb, so I think the 'layout regs' tries to analyse this few thousand instructions or whatever. Is there a way to tell 'layout regs' to show only the few surrounding instructions? Thomas