From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58807 invoked by alias); 18 Oct 2016 19:19:40 -0000 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 Received: (qmail 58792 invoked by uid 89); 18 Oct 2016 19:19:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=disp, startup_32, vmlinux, start_kernel X-HELO: mail-oi0-f42.google.com Received: from mail-oi0-f42.google.com (HELO mail-oi0-f42.google.com) (209.85.218.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 18 Oct 2016 19:19:29 +0000 Received: by mail-oi0-f42.google.com with SMTP id t73so4516326oie.1 for ; Tue, 18 Oct 2016 12:19:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LR6OZI1rp7jfCf3GKs/LIh9OXUHpWX1Lc2sPB9xUUTY=; b=YyXP20U+/4+B1noxaf+jHt8QjoxDU8Zw0qQapXs/8osguwhzX6e/LHSOhoAPqiWL8P DIZZxcINy7AuBQhgi/GTHgDp6fF3a51+fqGReMb9a8Z8z6qfngWvKT+qEcr3LHrCwEu7 CG8SCFzvXOZov440mYSTEklyxxRqjbZD6qdnl5ZIYleN6my8kSuJ+S2jXnciDtqmzEQO cORRfCgZuoHsDXqugrWL0YqBAhlqbCHCoQkjjgAW9WU6OL2454Ng/dXecN+Yeidrgr3Q M6ApKgUVb+reFlnVDKbtTJJqDsOKDVj610FagrQKbs8uguHgjbV1q1URrBhv52o8AeyS DDMw== X-Gm-Message-State: AA6/9RlgeJdA9z9s/mWYV1zd4WLKGNIk7nCnCQMPV4InTJq2dViRHyXuODyt2WpbcFH3aUlL+XRuS/U1eU28QQ== X-Received: by 10.157.49.100 with SMTP id v33mr1208450otd.5.1476818367721; Tue, 18 Oct 2016 12:19:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.193.5 with HTTP; Tue, 18 Oct 2016 12:19:27 -0700 (PDT) In-Reply-To: References: From: Yao Qi Date: Tue, 18 Oct 2016 19:19:00 -0000 Message-ID: Subject: Re: GDB does not stop at assembly code address To: deffo@gmx.de Cc: GDB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00028.txt.bz2 On Tue, Oct 18, 2016 at 12:53 PM, wrote: > Here's the output: > > (gdb) b startup_32 > Breakpoint 1 at 0xc1000000: file arch/x86/kernel/head_32.S, line 97. > (gdb) print startup_32 > $1 =3D {} 0xc1000000 > (gdb) info breakpoints > Num Type Disp Enb Address What > 1 breakpoint keep y 0xc1000000 arch/x86/kernel/head_32.S:97 > > (gdb) b start_kernel > Breakpoint 1 at 0xc1be3755: file init/main.c, line 480. > (gdb) print start_kernel > $1 =3D {void (void)} 0xc1be3755 > (gdb) info breakpoints > Num Type Disp Enb Address What > 1 breakpoint keep y 0xc1be3755 in start_kernel at init/main.c= :480 > Looks breakpoint is set on the right place. Nothing wrong there. > I guess the "no debug info" would be the explanation, but why is that? Th= e address is listed as a FUNC in readelf -Ws vmlinux, thus it should be cor= rect. What do I have to do? > "no debug info" is about startup_32, which is written in assembly without d= ebug information. It is nothing wrong there. I have no idea why breakpoint on startup_32 is not hit. --=20 Yao (=E9=BD=90=E5=B0=A7)