Re: can target code change architecture setting?

[Yao Qi <qiyaoltc at gmail dot com>]

On Mon, Oct 10, 2016 at 5:48 PM,  <duane@duaneellis.com> 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 (齐尧)