[Upstream port] Adding register types and registers

[EvgeniiDidin]

In case of ARC we have arch-specific registers like "STATUS32", "DEBUG", etc. We use one routine to add default GDB and ARC-specific register types.

In cpu/arc related .tcl script we describe register-types and registers, which are available on target. This requires jimctl command handlers.

[anthony-kolesov]

Note that today some registers which are essential for the debugging have hardcoded definitions. For example here https://github.com/foss-for-synopsys-dwc-arc-processors/openocd/blob/master/src/target/arc_ocd.c#L195 code uses hardcoded information for STATUS32. Or here https://github.com/foss-for-synopsys-dwc-arc-processors/openocd/blob/master/src/target/arc32.c#L530 code has hardcoded info on caches.

At the same time there is a more flexible code, like here: https://github.com/foss-for-synopsys-dwc-arc-processors/openocd/blob/master/src/target/arc32.c#L763, it refers to registers and their field by name, and I consider this code superior, because it doesn't duplicate information on which bit or register name has what meaning - connection through names is better. Although it is still not perfect, for example, in theory parameters of caches can be read and fully configured in TCL scripts as well, I think - that would be even better.

My opinion is that it would be better to replaces instances of code that use hardcoded register definitions with approach that relies on register/field names - it is something that I wanted to do after implementing registers in TCL, but never had the time to do. Though it is possible there could be some functions which are executed very early, before register definitions are read from TCL, so those functions would have to use hardcoded info, but that should use IDENTITY, DEBUG and STATUS32 at most, if at all. However, there is a concern that getting register by name is done by scanning linked list, so log(N), so in some cases you may need to either cache pointer to register object, or keep using the hardcoded definitions.

Also the more of this stuff you'd move to TCL, the more flexible it will be. For example, function https://github.com/foss-for-synopsys-dwc-arc-processors/openocd/blob/master/src/target/arc32.c#L751, that sets up CCM parameters - arc32_common fields can be exposed as TCL properties, then those checks, based on register field values can be done in TCL and then they would set arc32_common fields. Perhaps, this should be done only after the initial upstreaming, though.

[EvgeniiDidin]

Commits, related to adding reg_types:
8f734b0
e12b557

[EvgeniiDidin]

Commit, related to adding registers from tcl:
ace638d

[EvgeniiDidin]

Commit, adding building register caches function:
55d9df4

[EvgeniiDidin]

TODO after JTAG functionality introduction:

1. Introduce arc_regs_get(set)_core_reg functions
2. introduce get_register_value and register_get_by_name functions

[EvgeniiDidin]

Commit, introducing arc_regs_get(set)_core_reg functions:
2c1c26e
Commit, introducing arc_register_get_by_name:
e6f7cf6

[EvgeniiDidin]

Commits, introducing arc_get_register_field function:
0734496 c13bf9c
Commit, introducing arc_get/set_register_value functions:
3ad1583