On Mon, Mar 26, 2018 at 1:30 AM, Matthias Welwarsky <
matthias.welwar...@sysgo.com> wrote:
You could start by explaining why it is necessary for RISC-V. Why would gdb
> even ask for a register that doesn't exist? gdb normally only knows about
> registers that OpenOCD sends through an XML description that details which
> registers the target supports and their format. If the RISC-V support code
> provided such a message to GDB, would this patch still be needed?
>
RISC-V has up to 4096 control and status registers (CSRs), somewhat
analogous to MIPS’ coprocessor registers. There is no foolproof way to
determine which CSRs a given target supports, so in some cases it’s
unavoidable that a debugger might ask for registers that don’t exist on a
given target. I have some ideas on how to improve the XML list we send to
gdb, but in the end they are heuristics and there will still be some cases
where gdb might ask for a register that it turns out doesn’t exist.
Also, if this patch is genuinely useful, why do ARM targets break when it's
> enabled?
>
That’s a good question, and I only have a partial answer. There’s a debug
log in the first comment of
https://github.com/riscv/riscv-openocd/issues/115
The crucial part is:
Debug: 382 1052 gdb_server.c:2868 gdb_input_inner(): received packet: 'g'
Debug: 383 1053 gdb_server.c:1174 gdb_get_registers_packet(): Couldn't
get register r0.
Debug: 384 1053 gdb_server.c:1386 gdb_error(): Reporting -304 to GDB
as generic error
Debug: 385 1053 gdb_server.c:1022 gdb_connection_closed(): GDB Close,
Target: M2S090.cpu, state: reset, gdb_actual_connections=0
I haven’t looked into why r0 wasn’t readable nor into why gdb decided to
close the connection when it got that response. But given that gdb behaves
that way for ARM targets, it seems best not to report errors to it unless
we know it can handle them with grace.
I hope this clarifies things. If it doesn’t, please ask me more.
Tim
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
