can target code change architecture setting?

Yao Qi
Tue Oct 11 11:48:00 GMT 2016

On Mon, Oct 10, 2016 at 5:48 PM,  <> wrote:
> 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.

I am not sure GDB is able to unwind from kernel code to user space app.

> 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?

There is nothing special about RISCV.  In GDB, each frame has an
instance of gdbarch, and they can be different in the frames in the
backtrace.  PPC/SPU debugging is supported this way, IIUC.  That
is, frame #0 and frame #1 is of gdbarch1, and frame #2, and frame #3
is of gdbarch2.  It is possible in GDB nowadays.

> Question #2 - How should the remote debugger respond to GDB?
>       I don't think there is an "architecture change" packet.

Such packet is not needed, because GDB has to determine the gdbarch
of each when unwinding.

Yao (齐尧)

More information about the Gdb mailing list