Comments (14)
OpenOCD's reg
command (as used from the telnet interface) shows x0--x31.
It would be ideal to display/accept the symbolic names, while still accepting x0--x31.
from riscv-openocd.
OpenOCD's reg command (as used from the telnet interface) shows x0--x31.
I think this is one of the problems, that your expected use case is calibrated for manual usage.
In Eclipse there are several views, with different information. One is the Disassembly view, where register names use the ABI convention. Another one is the Registers view, where registers currently have the x%d
names. If I try to identify the content of the registers refered in the assembly view, I need to open a separate browser with the ABI table, which is very awkward.
In other words, the list of registers shown in the Registers view must use the same convention as the Disassembly view (the ABI convention).
If I remember right, in QEMU the register names were defined in an XML file, passed to GDB during initialisation, then Eclipse got these names from GDB.
I did not study the OpenOCD implementation, but I guess something similar happens here; somehow you pass a list of names from OpenOCD (as a GDB server) to the GDB client.
My suggestion is to make this list use the ABI names, the rest should be ok in GDB and indirectly in Eclipse.
It would be ideal to display/accept the symbolic names, while still accepting x0--x31.
If 'still accepting x0--x31' pertains only to the manual OpenOCD interface, feel free to use any naming conventions you want; I'm only interested in consistency in the Eclipse views.
from riscv-openocd.
I believe that the RISC-V register names are hardcoded in gdb, and are not transmitted from OpenOCD using the XML file mechanism. But I don't have a thorough understanding on how everything gets its names.
The use case I'm focusing on is gdb, assuming that if gdb works well then tools built on top of gdb will also work well. info registers
in gdb does show symbolic names.
from riscv-openocd.
From the point of view of the Eclipse General Registers view, once GDB is fixed via riscvarchive/riscv-binutils-gdb#111, this issue can be closed. I'm not sure if register names shown by monitor reg
use the GDB names, or the definitions are local, and in this case need to be updated separately.
from riscv-openocd.
the RISC-V register names are hardcoded in gdb
poor choice. :-(
ARM GDB gets the register names from the GDB server.
how does GDB know the core type, to display or not the FP registers? in the example I know, QEMU knows the core type, and in ARM case, passes different XMLs, with or without FP registers.
I see no reason for OpenOCD not to use the same approach.
from riscv-openocd.
I agree that having OpenOCD pass an XML file to gdb would be better. ISTR looking at it and couldn't find any documentation or clear example on how that is supposed to work.
from riscv-openocd.
that if gdb works well then tools built on top of gdb will also work well
Eclipse uses the MI interface, not the manual interface.
couldn't find any documentation or clear example on how that is supposed to work.
yes, documentation is probably inadequate. did you also check the linux gdbserver? the XML passing may be used there too.
from riscv-openocd.
for reference, here is a link to the file I modified in QEMU: https://github.com/gnu-mcu-eclipse/qemu/blob/gnuarmeclipse-dev/gdb-xml/arm-cortexm.xml
from riscv-openocd.
and, as the comment mentions, the same XML mechanism is used by SEGGER JLinkGDBserver.
from riscv-openocd.
Yes, we know about the XML mechanism and it's the right thing to do. This was brought up as part of the GDB upstreaming process, I just haven't had time to look at it.
from riscv-openocd.
ok, then I suggest to keep this ticket open and check again how register names reach Eclipse when the XML mechanism is functional.
from riscv-openocd.
riscvarchive/riscv-binutils-gdb#73
from riscv-openocd.
FWIW I made a (very inelegant! :-) hack to GDB's riscv-tdep.c (attached - renamed to riscv-tdep.c.txt because *.c files won't upload for some reason) so that ABI rather than canonical names are returned. For the moment I build GDB with this hack until such time as there is a proper solution using the target description XML mechanism which I hope to look at and maybe produce a strawman mod. Note that in draft priv spec "only" c. 200 of the possibly 4096 CSRs are implemented/allocated. It would be an improvement if the relevant register commands returned only these rather than all 4096 possible regs. (Even then do users really need ANY CSRs every time?).
I think that using the GDB target description XML mechanism it may be possible to support different register sets based on the target architecture (deduced from misa or other CSRs or else passed via GDB's set architecture command). E.g. ABI names for the following:
- if E extension then integer regs x0-x15 otherwise all integer regs x0-x31
- if G/F/D/Q extension then floating point regs fp0-fp31 otherwise none of these
- only CSRs actually implemented/allocated in the latest priv spec (may be further tunable based on target capabilities?)
- pc and priv always implemented/returned
riscv-tdep.c.txt
from riscv-openocd.
See https://github.com/riscv/riscv-openocd/blob/riscv/src/target/register.h#L120-L121
struct reg {
/* Canonical name of the register. */
const char *name;
...
};
Canonical names are: x##, f##, csr#### (see ISA spec).
Typically gdb defines own ABI aliases for canonical names. The reverse is not true.
If you want to use "pretty" ABI names in OpenOCD, you can define TCL variables:
> set s0 x8
x8
> set fp x8
x8
> reg $fp
x8 (/32): 0xF00004E8
> reg $s0
x8 (/32): 0xF00004E8
Revert your changes, please.
from riscv-openocd.
Related Issues (20)
- load_image returns error 'invalid command' HOT 6
- Q extension support HOT 3
- how to read v register if vslide1down instruction not present HOT 19
- Using the `info reg all` command within gdb returns an `remote failure reply 'E0E'` HOT 10
- Issues Flashing Baremetal Applications Directly with OpenOCD on MPFS HOT 2
- Cache information about abstract access availability on per-register basis
- Implement controls to adjust OpenOCD behavior during when it tries to detect which watch point was hit (riscv_hit_watchpoint)
- How can I build openocd with static libs? HOT 13
- Investigate the semantics of step/resume operations in context of HW trigger state.
- `read_memory_bus_v1()` is broken HOT 1
- RISC-V v0.11: Writes to register `x0` (`zero`) should not be cached.
- progbuf issue HOT 7
- Unnecessary calls to `select_dmi()`
- Some header guards do not comply to style guide
- All `targets/RISC-V/spike32.py` tests failing HOT 6
- openocd only supports Debug Module version 2 (0.13) and 3 (1.0), not 0 (dmstatus=0x0). This error might be caused by a JTAG signal issue. Try reducing the JTAG clock speed HOT 12
- read_memory_bus_v1 does not work properly for sizes greater than 4 HOT 1
- There are cases when WPs disabled by `disable_triggers()` can not be re-enabled by `enable_triggers()`. HOT 2
- How to program multiple cores using Openocd ? HOT 3
- Invalided cache for breakpoints HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from riscv-openocd.