RE: can target code change architecture setting?

<[email protected]>
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.