can target code change architecture setting?

can target code change architecture setting?

[Tim Newsome]

I’m working with riscv gdb support. One problem people occasionally
run into is that riscv has both 32- and 64-bit variants. The current
gdb code just assumes 64-bit by default (unless a file is specified,
and then it gets the info from the ELF info). If such a gdb connects
to a 32-bit target, bulk register reads end up wonky, and writes send
too much data which confuses OpenOCD. Currently the user needs to do
something like set arch riscv:rv32 to work around this.

Is it possible for riscv-tdep.c to have some kind of callback function
that is called when gdb connects to a server, and for that function to
change the register width? If so, gdb could read the riscv misa
(instruction set architecture information) register and transparently
reconfigure.

I looked, but I didn’t see any obvious callbacks that get called when
connecting to a target.

Thank you,
Tim

Re: can target code change architecture setting?

[Yao Qi]

On Fri, Oct 7, 2016 at 6:38 PM, Tim Newsome <tim@sifive.com> wrote:
> I’m working with riscv gdb support. One problem people occasionally
> run into is that riscv has both 32- and 64-bit variants. The current
> gdb code just assumes 64-bit by default (unless a file is specified,
> and then it gets the info from the ELF info). If such a gdb connects
> to a 32-bit target, bulk register reads end up wonky, and writes send
> too much data which confuses OpenOCD. Currently the user needs to do
> something like set arch riscv:rv32 to work around this.
>
> Is it possible for riscv-tdep.c to have some kind of callback function
> that is called when gdb connects to a server, and for that function to
> change the register width? If so, gdb could read the riscv misa
> (instruction set architecture information) register and transparently
> reconfigure.
>
> I looked, but I didn’t see any obvious callbacks that get called when
> connecting to a target.
>

I don't know much about riscv, so I assume 32-bit variant and 64-bit
variant can _not_ co-exist in one program.  If so, each variant can
be abstracted as a gdbarch.

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.  I assume riscv 32-bit and 64-bit variants have
different registers.

In GDB side, you need two gdbarch instances, 32-bit riscv and 64-bit
riscv.  In riscv_gdbarch_init, look for the feature from the target
description (sent by OpenOCD for example), if 32-bit is found, create
and return gdbarch for 32-bit; if 64-bit is found, create and return
gdbarch for 64-bit.

If 32-bit variant and 64-bit one is quite different, you even can create
two tdep.c files, like riscv32-tdep.c and risc64-tdep.c.

-- 
Yao (齐尧)

Re: can target code change architecture setting?

[Tim Newsome]

That sounds like a good solution. I'll see if I can make it happen.

Thanks, Yao!

Tim

On Mon, Oct 10, 2016 at 2:26 AM, Yao Qi <qiyaoltc@gmail.com> wrote:
> On Fri, Oct 7, 2016 at 6:38 PM, Tim Newsome <tim@sifive.com> wrote:
>> I’m working with riscv gdb support. One problem people occasionally
>> run into is that riscv has both 32- and 64-bit variants. The current
>> gdb code just assumes 64-bit by default (unless a file is specified,
>> and then it gets the info from the ELF info). If such a gdb connects
>> to a 32-bit target, bulk register reads end up wonky, and writes send
>> too much data which confuses OpenOCD. Currently the user needs to do
>> something like set arch riscv:rv32 to work around this.
>>
>> Is it possible for riscv-tdep.c to have some kind of callback function
>> that is called when gdb connects to a server, and for that function to
>> change the register width? If so, gdb could read the riscv misa
>> (instruction set architecture information) register and transparently
>> reconfigure.
>>
>> I looked, but I didn’t see any obvious callbacks that get called when
>> connecting to a target.
>>
>
> I don't know much about riscv, so I assume 32-bit variant and 64-bit
> variant can _not_ co-exist in one program.  If so, each variant can
> be abstracted as a gdbarch.
>
> 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.  I assume riscv 32-bit and 64-bit variants have
> different registers.
>
> In GDB side, you need two gdbarch instances, 32-bit riscv and 64-bit
> riscv.  In riscv_gdbarch_init, look for the feature from the target
> description (sent by OpenOCD for example), if 32-bit is found, create
> and return gdbarch for 32-bit; if 64-bit is found, create and return
> gdbarch for 64-bit.
>
> If 32-bit variant and 64-bit one is quite different, you even can create
> two tdep.c files, like riscv32-tdep.c and risc64-tdep.c.
>
> --
> Yao (齐尧)

RE: can target code change architecture setting?

[duane]

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.

Re: can target code change architecture setting?

[Tim Newsome]

On Mon, Oct 10, 2016 at 9:48 AM,  <duane@duaneellis.com> wrote:

> Question #1 Is this dual mode possible in RISCV?

Not currently, and I don't think there will be a dual mode.

There was a proposal that should allow 32-bit code to just work on
64-bit architectures, but I'm pretty sure it was not by adding a
different mode. It sounded more like the MIPS model where the ISA is
cleverly defined to not care. But unfortunately I can't find the
e-mail thread right now.

> Question #2 - How should the remote debugger respond to GDB?

For RISCV, what I would want is for it to tell GDB that it's running
on 64-bit hardware, because it is. I see no reason to hide from the
user what's actually happening in the hardware.

Tim

Re: can target code change architecture setting?

[Yao Qi]

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 (齐尧)

Re: can target code change architecture setting?

[Duane Ellis]

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

I think you are making the assumption that GDB always has access to full debug (i.e.: dwarf) information.

In bare metal - You don’t always have this, you might have *labels* only (function name vrs address) but no source, no dwarf information.

The only solution is to *ask* the target “what is your *current* arch.

Or the target needs to send a “target-arch-change-indication” in some way.

-Duane.

Re: can target code change architecture setting?

[Doug Evans]

On Tue, Oct 11, 2016 at 7:29 AM, Duane Ellis <duane@duaneellis.com> wrote:
>>
>>> 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.
>
> I think you are making the assumption that GDB always has access to full debug (i.e.: dwarf) information.
>
> In bare metal - You don’t always have this, you might have *labels* only (function name vrs address) but no source, no dwarf information.
>
> The only solution is to *ask* the target “what is your *current* arch.
>
> Or the target needs to send a “target-arch-change-indication” in some way.

Agreed.

Consider booting some x86 kernel on qemu (e.g., passing -s -S to qemu).
At the start $pc is at the x86 reset location and the architecture is 16-bit.

(gdb) tar ext :1234
Remote debugging using :1234
0x000000000000fff0 in ?? ()

At some later point the o/s will switch to 32 or 64-bit mode but until
then gdb isn't as useful as one might want it to be.