From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30198 invoked by alias); 29 Nov 2005 06:01:07 -0000 Received: (qmail 30191 invoked by uid 22791); 29 Nov 2005 06:01:06 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.201) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Nov 2005 06:01:04 +0000 Received: by zproxy.gmail.com with SMTP id x3so2609735nzd for ; Mon, 28 Nov 2005 22:01:02 -0800 (PST) Received: by 10.36.227.10 with SMTP id z10mr4225643nzg; Mon, 28 Nov 2005 22:01:02 -0800 (PST) Received: by 10.37.2.35 with HTTP; Mon, 28 Nov 2005 22:01:02 -0800 (PST) Message-ID: <8f2776cb0511282201y3fcbd125w16da2303780954aa@mail.gmail.com> Date: Tue, 29 Nov 2005 10:13:00 -0000 From: Jim Blandy To: yang xiaoli Subject: Re: local gdb could not stop at breakpoint? Cc: gdb@sourceware.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00610.txt.bz2 On 11/28/05, yang xiaoli wrote: > I compile gdb6.0 for arm , now it works, but when I debug a program and s= et > breakpoint at a line, it does't stop at breakpoint, it runs over, for > example like this: > > (gdb)l > 1 #include > 2 int main() > 3 { > 4 int a, b; > 5 > 6 a =3D 10; > 7 b =3D 20; > 8 printf("hello world\n"); > 9 printf("a+b=3D %d", a+b); > (gdb)b 6 > (gdb)r > Startomg program... > hello world > a+b=3D 30 > > Program exited normally > (gdb) > > when I see breakpoints using command "info b" ,it display the breakpoints > information normally, why it does not stop at breakpoints? When you post a bug report, or a question like this, it's important to provide all the information we would need to try things out on our own machine (assuming we have an ARM-linux system handy, which some of us do). In this case: - You haven't included complete source code for your test program. - You haven't showed us how you compiled it. - You have clipped out sections of the GDB transcript that would tell us how you're connecting to the target --- target remote, native, etc. But I remember from your previous message that you're doing native debugging, so that's fine. - Since you're doing native debugging, we might need to know which kernel you're running. As I say, think of what another GDB developer would need to know in order to make the problem happen themselves. My first suggestion: have you tried a more recent version of GDB? 6.0 is around two years old.