This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: can target code change architecture setting?


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]