From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26049 invoked by alias); 11 Oct 2016 11:48:01 -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 26015 invoked by uid 89); 11 Oct 2016 11:48:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.9 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=Question, dual, corruption, halt 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, 11 Oct 2016 11:47:50 +0000 Received: by mail-oi0-f42.google.com with SMTP id d132so20028235oib.2 for ; Tue, 11 Oct 2016 04:47:50 -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=HjVqsZ+85ylO7AGgqsg/WsnA+CkFW0sI46NpDs9CEEo=; b=PB8SoZUHWNwqxkQ8s1uQAvB+2lUCq+U6MYoooEesS6al0QlfFTUp+BXV+4lxINaoIR Lv4IcoWbdZEH7SPryYgcBwGZ7u1lcniMK6NfoVz5vZK7rUJmVOJyNhhF5Ae84VzIvWjb 7YiLZGgGXLaUgYSw+69QRHs55+1dRqMEf3E3kEdV5X3oU9if7VBq8YdEpskmXVQE5B07 3WttgOmLxDT9QujD8/dUnlgKtJSRj07QEJ5/QgFp+z37ga8yj80GRHk33+euMjt+oRIs 2/RnZYbCP5W89kC55N9GDaMQDU8Qm11TszepsOtaV4KPSqJQJUccjB0xnCWjALKRSnVX cObQ== X-Gm-Message-State: AA6/9RmTgDD5PhThSaIDXw3BE3k+RgDtpCqAJnw/xE4ruX+BcjpkCjIenLSv/usyPzL/QdtL/hyVbxMLnJ53MA== X-Received: by 10.202.228.69 with SMTP id b66mr2090877oih.31.1476186468749; Tue, 11 Oct 2016 04:47:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.221.3 with HTTP; Tue, 11 Oct 2016 04:47:48 -0700 (PDT) In-Reply-To: <20161010094844.5c1bb9f86d671edec44bb378f25c04cc.aef8a9655c.wbe@email03.godaddy.com> References: <20161010094844.5c1bb9f86d671edec44bb378f25c04cc.aef8a9655c.wbe@email03.godaddy.com> From: Yao Qi Date: Tue, 11 Oct 2016 11:48:00 -0000 Message-ID: Subject: Re: can target code change architecture setting? To: duane@duaneellis.com Cc: Tim Newsome , gdb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00020.txt.bz2 On Mon, Oct 10, 2016 at 5:48 PM, wrote: > > However in the bare metal case, I have a question about RISCV (and > arm-arch64) > > In Arm-ARCH64 - you can have both 32bit application, and 64bit kernel. > I'm not sure about the x86_64 case - because I am not familiar with bare > metal debug there. > I am not sure GDB is able to unwind from kernel code to user space app. > As a result, when a "jtag-halt" (aka: Bare metal halt) the CPU may halt > in either mode. > > Described another way: > > You are stepping through 32bit user space code. > Set a breakpoint. > Click RUN > > Option 1: > The 64bit kernel crashes, and the jtag debugger reports HALT > but the registers are 100% wrong. > > Option 2: > A hardware read/write breakpoint is configured > And that hardware break point is triggered. > maybe you are debugging memory corruption issues, these things > happen > > Option 3: > The program is taking a long time, the human hits "control-C" > GDB sends a stop/halt packet > And the CPU stops/halts in 64bit mode > > Question #1 Is this dual mode possible in RISCV? > There is nothing special about RISCV. In GDB, each frame has an instance of gdbarch, and they can be different in the frames in the backtrace. PPC/SPU debugging is supported this way, IIUC. That is, frame #0 and frame #1 is of gdbarch1, and frame #2, and frame #3 is of gdbarch2. It is possible in GDB nowadays. > Question #2 - How should the remote debugger respond to GDB? > > I don't think there is an "architecture change" packet. > Such packet is not needed, because GDB has to determine the gdbarch of each when unwinding. --=20 Yao (=E9=BD=90=E5=B0=A7)