This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: can target code change architecture setting?
- From: <duane at duaneellis dot com>
- To: "Tim Newsome" <tim at sifive dot com>, "Yao Qi" <qiyaoltc at gmail dot com>
- Cc: "gdb" <gdb at sourceware dot org>
- Date: Mon, 10 Oct 2016 09:48:44 -0700
- Subject: RE: can target code change architecture setting?
- Authentication-results: sourceware.org; auth=none
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.
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?
I don't think there is an "architecture change" packet.
Thanks.