gdb(4): allow bulk write and single read of registers

[mhorne]

Summary

Corresponding to the 'G' and 'p' packets in the GDB remote protocol.

https://sourceware.org/gdb/onlinedocs/gdb/Packets.html

Test Plan

This, along with D27642, are supposedly enough to allow basic usage of the
'call' command with NetApp's GDB client. While this still doesn't quite work
with kgdb, I was able to observe single register reads execute successfully. I
am not sure what commands are required to have kgdb issue a bulk register
write.

[cem]

sys/gdb/gdb_main.c

710

This error case breaks the for loop and then Tx’s ok?

[cem]

(Otherwise, lgtm)

[jhb]

I might split these into two. I suspect only 'p' is actually needed for call, but it doesn't hurt to have G I guess?

Ideally though, this would fail if we can't read/write a given register. This doesn't work because the register read/write hooks return void and don't report when they failed to adjust a register, so fixing that requires a bigger change.

[mhorne]

In D27644#618098, @jhb wrote:

I might split these into two. I suspect only 'p' is actually needed for call, but it doesn't hurt to have G I guess?

Sure, it seems to make sense to split it. The patch I am working from added both, but after a bit of searching in GDB I can't find a distinct use-case for G. It seems to be more of a fallback for when P is not supported.

Ideally though, this would fail if we can't read/write a given register. This doesn't work because the register read/write hooks return void and don't report when they failed to adjust a register, so fixing that requires a bigger change.

Agreed, although I didn't want to gate this change behind that extra work. I will look further into the use-case for G packets from NetApp's POV, and if that too is nothing more than "doesn't hurt to have", it's likely not worth the added effort.

Does the p packet handling seem fine? I will move forward with that first if so.

sys/gdb/gdb_main.c

710

Thanks, will address this.

[jhb]

In D27644#618200, @mhorne wrote:

Ideally though, this would fail if we can't read/write a given register. This doesn't work because the register read/write hooks return void and don't report when they failed to adjust a register, so fixing that requires a bigger change.

Agreed, although I didn't want to gate this change behind that extra work. I will look further into the use-case for G packets from NetApp's POV, and if that too is nothing more than "doesn't hurt to have", it's likely not worth the added effort.

Agreed.

Does the p packet handling seem fine? I will move forward with that first if so.

Yes, and I think it's fine to not gate that on the error handling. The error handling would be more of a "nice to have", though it might also give you more sensible errors in the debugger for something like call vs things failing for odd reasons.

[mhorne]

Don't transmit "ok" for the error case.

[cem]

Thanks!

sys/gdb/gdb_main.c

716

Success here is equivalent to r >= GDB_NREGS. Not a big deal.