RE: can target code change architecture setting?
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <20161010094844.5c1bb9f86d671edec44bb378f25c04cc.aef8a9655c.wbe@email03.godaddy.com> |
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.