From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22236 invoked by alias); 10 Oct 2016 16:48:50 -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 22225 invoked by uid 89); 10 Oct 2016 16:48:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.0 required=5.0 tests=BAYES_20,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=dual, halt, corruption, HALT X-HELO: p3plwbeout03-05.prod.phx3.secureserver.net Received: from p3plsmtp03-05-2.prod.phx3.secureserver.net (HELO p3plwbeout03-05.prod.phx3.secureserver.net) (72.167.218.217) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Oct 2016 16:48:48 +0000 Received: from localhost ([72.167.218.135]) by p3plwbeout03-05.prod.phx3.secureserver.net with bizsmtp id tsom1t0032vs63s01somsF; Mon, 10 Oct 2016 09:48:46 -0700 X-SID: tsom1t0032vs63s01 Received: (qmail 27308 invoked by uid 99); 10 Oct 2016 16:48:46 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" User-Agent: Workspace Webmail 6.5.1 Message-Id: <20161010094844.5c1bb9f86d671edec44bb378f25c04cc.aef8a9655c.wbe@email03.godaddy.com> From: To: "Tim Newsome" , "Yao Qi" Cc: "gdb" Subject: RE: can target code change architecture =?UTF-8?Q?setting=3F?= Date: Mon, 10 Oct 2016 16:48:00 -0000 Mime-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00018.txt.bz2 Yao> > You need to add two target descriptions for 32-bit and 64-bit variants > respectively, and OpenOCD need to send back the right target > description to GDB.=20 Tim>> That sounds like a good solution. I'll see if I can make it happen. For an application level, I think this is 100% correct. 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. 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? Question #2 - How should the remote debugger respond to GDB? =20 I don't think there is an "architecture change" packet. Thanks.