On Montag, 26. März 2018 23:15:17 CEST Tim Newsome wrote: > 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.
Hm, that's actually not unusual, other architectures also have status registers that are not implemented in certain silicon revisions, but normally you have ID registers that allow a debugger (or application software) to find out which are available and which aren't. If that's not possible for RISC-V, then, ok, we have to cope with that in some way. > 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. Well 'r0' is unreadable (in fact any register is) because your tree doesn't include the following patch: http://openocd.zylin.com/#/c/4432/ You last merged openocd master here: https://github.com/riscv/riscv-openocd/commit/ c2b2a7a3b84913465420ae7fa0394304943cf035 which is a patch from September last year. The main reason for the error is that openocd used to not change the target state when gdb attaches - that was useful on cortex_m for some special use cases but effectively it caused a lot of problems elsewhere and so the default was changed to always halt the target on gdb-attach. However, reporting an error to gdb doesn't seem to be all that useful. I've been trying with a Cortex-M target (STM32F303) and effectively the error prevents gdb from fetching all registers from the target. Here's what I get on "info reg": Debug: 585 5119 gdb_server.c:3129 gdb_input_inner(): received packet: 'p27' Debug: 586 5119 gdb_server.c:1308 gdb_get_register_packet(): Couldn't get register fpscr. Debug: 587 5119 gdb_server.c:1388 gdb_error(): Reporting -4 to GDB as generic error Whereas without error propagation: Debug: 585 5031 gdb_server.c:3129 gdb_input_inner(): received packet: 'p27' Debug: 586 5031 gdb_server.c:3129 gdb_input_inner(): received packet: 'p11' Debug: 587 5032 cortex_m.c:1509 cortex_m_load_core_reg_u32(): load from core reg 17 value 0x20000400 Debug: 588 5032 gdb_server.c:3129 gdb_input_inner(): received packet: 'p12' Debug: 589 5032 cortex_m.c:1509 cortex_m_load_core_reg_u32(): load from core reg 18 value 0x20000bd8 Debug: 590 5033 gdb_server.c:3129 gdb_input_inner(): received packet: 'p13' Debug: 591 5033 cortex_m.c:1563 cortex_m_load_core_reg_u32(): load from special reg 19 value 0x0 Debug: 592 5033 gdb_server.c:3129 gdb_input_inner(): received packet: 'p14' Debug: 593 5033 cortex_m.c:1563 cortex_m_load_core_reg_u32(): load from special reg 20 value 0x0 Debug: 594 5034 gdb_server.c:3129 gdb_input_inner(): received packet: 'p15' Debug: 595 5034 cortex_m.c:1563 cortex_m_load_core_reg_u32(): load from special reg 21 value 0x0 Debug: 596 5034 gdb_server.c:3129 gdb_input_inner(): received packet: 'p16' Debug: 597 5035 cortex_m.c:1563 cortex_m_load_core_reg_u32(): load from special reg 22 value 0x2 Is that different on gdb for RISC-V? -- Mit freundlichen Grüßen/Best regards, Matthias Welwarsky Project Engineer SYSGO AG Office Mainz Am Pfaffenstein 14 / D-55270 Klein-Winternheim / Germany Phone: +49-6136-9948-0 / Fax: +49-6136-9948-10 VoIP: SIP:m...@sysgo.com E-mail: matthias.welwar...@sysgo.com / Web: http://www.sysgo.com _________________________________________________________________________________ Web: https://www.sysgo.com Blog: https://www.sysgo.com/blog Events: https://www.sysgo.com/events Newsletter: https://www.sysgo.com/newsletter _________________________________________________________________________________ Handelsregister/Commercial Registry: HRB Mainz 90 HRB 8066 Vorstand/Executive Board: Etienne Butery (CEO), Kai Sablotny (COO) Aufsichtsratsvorsitzender/Supervisory Board Chairman: Marc Darmon USt-Id-Nr./VAT-Id-No.: DE 149062328 ------------------------------------------------------------------------------ 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
