| RE: [dsdp-dd-dev] register mappings in debuggers |
I suppose that it would help if I did in fact supply a couple of examples of what I am looking for, so here goes: 1) DecoderElfPPC.ini: this file has mappings from dwarf2 register indexes to register id's for PowerPC for the Microtec C/C++ compiler. Our EDGE debugger uses this to load the mapping at run time so that it isn't hard coded. 2) current_edge_mdi_arm_mapping_example.xml: this xml file contains mapping from register id's to MDI debug API resources/offsets for the ARM architecture. It is also a little interesting in that we used regular expressions to help deal with coprocessor registers. I am hoping to see or hear about some other examples, and/or have someone bring out some other possible uses for mappings (disassemblers? compilers?) Perhaps I implied this in the previous message, but I am envisioning that we would not restrict what this mapping schema could be used for btw. Just standardize a few enums of "type" of mapping so that a debugger could know to pick the common ones it needs. You could of course use the same schema for some completely different type of mapping... cheers, aaron -----Original Message----- From: dsdp-dd-dev-bounces@xxxxxxxxxxx [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Spear, Aaron Sent: Saturday, September 08, 2007 8:50 AM To: Device Debugging developer discussions Subject: [dsdp-dd-dev] register mappings in debuggers Hello everyone, One thing that I have been working on a bit in the SPIRIT/IP-XACT debug working group is coming up with a schema to be a part of IP-XACT that describes mappings between register id's in cores and peripherals and other information that debuggers need. The two operative examples of where these mappings are needed in a debugger that I can come up with are mappings from: 1) standard register id's to compiler register id's (e.g. dwarf register indexes) 2) standard register id's to a proprietary format used for a debugger back end of some kind. i.e. a string of whatever format used for a particular probe or simulator for access to registers (e.g. GDB server register indexes) The general idea here is that we would like to have a scenario where someone may get CPU IP from company A who supplies the customer with an IP-XACT component for their CPU, the customer may then buy a compiler from company B because it has whiz-bang optimization, a probe from company C and a debugger from company D. In an ideal world, both the compiler and probe vendors would supply standard format mapping files in this standard schema, and the customer could drop them into their design environment. Then when the debugger gets around to trying to debug this design, they not only get the hardware information in terms of what registers/peripherals are in the system, but they also get files that have the dwarf index mapping and mapping for whatever API the probe uses, and they are all in sync (what a concept). Mentors debuggers use many permutations of proprietary files to supply this type of information currently, and they all do basically doing the same thing (some ini files, some XML files, ...) and I would be happy to throw them all away in favor of a standard. The Questions: (finally) 1) Does anyone have other ideas where this sort of mapping between register id's and something else is useful? 2) if you have any examples of mappings used by your commercial tools that you would be willing to send my way I would appreciate seeing them. This point is important, because I want to be able to think about the different ways people are doing things. We for example have one schema in which we use regular expressions to parse register id's to construct the id's used to access the registers in a certain probe API. This is very convenient because they when new registers are added we don't have to modify these files and it just works (mostly) thanks! Aaron -- Aaron Spear Debug Tools Architect/Staff Engineer Mentor Graphics aaron_spear@xxxxxxxxxx 303-679-8457 _______________________________________________ dsdp-dd-dev mailing list dsdp-dd-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
Attachment:
DecoderElfPPC.ini
Description: DecoderElfPPC.ini
<!-- ********************************************************************** --> <!-- ********************************************************************** --> <!-- Copyright (c) 2004 Mentor Graphics Corp. --> <!-- --> <!-- PROPRIETARY RIGHTS of Mentor Graphics Corp. are involved in the --> <!-- subject matter of this material. All manufacturing, reproduction, --> <!-- use, and sales rights pertaining to this subject matter are governed --> <!-- by the license agreement. The recipient of this software implicitly --> <!-- accepts the terms of the license. --> <!-- ********************************************************************** --> <!-- ********************************************************************** --> <!-- Description: EDGE Transport description file (MDI) --> <!-- ********************************************************************** --> <!-- Revisions: ** --> <!-- ********************************************************************** --> <!-- TRANSPORT --> <transport name="MDI" description="Microprocessor Debug Interface" version="1.0"> <!-- AARON SNIPPED A WHOLE LOT OF STUFF OUT HERE --> <!-- ******************** REGISTER MAPPINGS *********************************** MDI REGISTER ACCESS RESOURCE AND OFFSET MAPPING README: To access registers, MDI uses a resource id and an offset to uniquely describe all registers. This section describes the mapping for different families/cores of edge register id to resource/offset pair. There are currently three different mechanisms used to figure out out the mapping (this may be normalized in the future as this is hard to understand why the heck we need the first one) 1) hex numbers: in this case the number is a hex value without any starting "0x" on the front of it. The formula for the resource/offset is [group, 1 or more hex digits][bank 3 hex digits][index, 2 hex digits] resource = group offset = (bank << 5) + index; e.g. <register from="CTL_1" to="300001"/> -> resource 3 offset 1 2) strings that start with R. "R,<resource>,<offset>" where resource and offset are DECIMAL integer values. (nice and simple eh? why the heck wasn't the approach above done like this?) e.g. <register from="R15_usr" to="R,2,15"/> -> resource 2 offset 15 3) strings that start with C: for ARM, coprocessor registers have an interesting encoding in the offset value which tells you how to construct the ARM MCR/MPR instruction to be used to write/read the value. See the verbose comment below on how the formula works. e.g. <register from="CP15_0_C2_C0_0" to="C,15,0,2,0,0"/> usage of regular expressions: Note that if it is applicable or convenient, you can use a syntax that uses 'from_regex' and 'to_regex' instead of from/to, and a mostly posix regular expression find/replace will be done on the string. This can save you a LOT of register mappings in the case that you have a pattern that the mappings follow. ******************** REGISTER MAPPINGS *********************************** --> <core family="ARM"> <!-- Covers ARM7 and 9 cores --> <!-- Current --> <register from="R0" to="R,1,0"/> <register from="R1" to="R,1,1"/> <register from="R2" to="R,1,2"/> <register from="R3" to="R,1,3"/> <register from="R4" to="R,1,4"/> <register from="R5" to="R,1,5"/> <register from="R6" to="R,1,6"/> <register from="R7" to="R,1,7"/> <register from="R8" to="R,1,8"/> <register from="R9" to="R,1,9"/> <register from="R10" to="R,1,10"/> <register from="R11" to="R,1,11"/> <register from="R12" to="R,1,12"/> <register from="R13" to="R,1,13"/> <register from="R14" to="R,1,14"/> <register from="R15" to="R,1,15"/> <register from="SPSR" to="R,8,1"/> <!-- USR group --> <register from="R0_usr" to="R,2,0"/> <register from="R1_usr" to="R,2,1"/> <register from="R2_usr" to="R,2,2"/> <register from="R3_usr" to="R,2,3"/> <register from="R4_usr" to="R,2,4"/> <register from="R5_usr" to="R,2,5"/> <register from="R6_usr" to="R,2,6"/> <register from="R7_usr" to="R,2,7"/> <register from="R8_usr" to="R,2,8"/> <register from="R9_usr" to="R,2,9"/> <register from="R10_usr" to="R,2,10"/> <register from="R11_usr" to="R,2,11"/> <register from="R12_usr" to="R,2,12"/> <register from="R13_usr" to="R,2,13"/> <register from="R14_usr" to="R,2,14"/> <register from="R15_usr" to="R,2,15"/> <register from="CPSR" to="R,8,0"/> <!-- FIQ group --> <register from="R8_fiq" to="R,5,8"/> <register from="R9_fiq" to="R,5,9"/> <register from="R10_fiq" to="R,5,10"/> <register from="R11_fiq" to="R,5,11"/> <register from="R12_fiq" to="R,5,12"/> <register from="R13_fiq" to="R,5,13"/> <register from="R14_fiq" to="R,5,14"/> <register from="R15_fiq" to="R,5,15"/> <register from="SPSR_fiq" to="R,8,6"/> <!-- Supervisor group --> <register from="R13_svc" to="R,3,13"/> <register from="R14_svc" to="R,3,14"/> <register from="SPSR_svc" to="R,8,2"/> <!-- Abort group --> <register from="R13_abt" to="R,6,13"/> <register from="R14_abt" to="R,6,14"/> <register from="SPSR_abt" to="R,8,3"/> <!-- IRQ group --> <register from="R13_irq" to="R,4,13"/> <register from="R14_irq" to="R,4,14"/> <register from="SPSR_irq" to="R,8,5"/> <!-- Undefined group --> <register from="R13_und" to="R,7,13"/> <register from="R14_und" to="R,7,14"/> <register from="SPSR_und" to="R,8,4"/> <!-- Here is the official mdiarm.h comment on how the mapping between mdi offsets and ARM coprocessor registers works: /* Coprocessor registers for each coprocessor. * * For 32-bit registers, the MCR/MRC instructions include four fields * that can be combined by the CP to select a register: Op1 (b23:21, * CP specific opcode bits), Rn (b19:16, the CP src/dest reg), * Op2 (b7:5, CP specific opcode bits), and Rm (b3:0, the "additional * CP register"). The 16384 possible registers are addressed as * follows: * * Offset == Op1 << 11 | Rm << 7 | Op2 << 4 | Rn * * For 64-bit registers, the MCRR/MRRC instructions include two fields * that can be combined by the CP to select a register: Op (b7:4, * CP specific opcode bits), and Rm (b3:0, the CP src/dest reg). The * 128 possible registers addressed as follows: * * Offset == Op << 4 | Rm */ For EDGE from the register id we generate a string that then goes through the formula above to calculate the offset. So, we create a regular expression rule that parses the id and generates a string that meets the pattern we use to generate the offset by the formula above. This regular expression rule should work for all coprocessor regs. Delimiter,CP,OP1,Rn,Rm,OP2 --> <register from_regex="^CP([0-9]+)_([0-9]+)_C([0-9]+)_C([0-9]+)_([0-9]+)$" to_regex="C,\1,\2,\3,\4,\5"/> <!-- aaron note: these mappings could probably be put into the rule as well by making the rule a bit smarter (to cover/ignore the trailing underscore and text, e.g. _MMU --> <register from="CP15_0_C2_C0_0_MMU" to="C,15,0,2,0,0"/> <register from="CP15_0_C2_C0_0_MPU" to="C,15,0,2,0,0"/> <register from="CP15_0_C3_C0_0_MMU" to="C,15,0,3,0,0"/> <register from="CP15_0_C3_C0_0_MPU" to="C,15,0,3,0,0"/> <register from="CP15_0_C5_C0_0_MMU" to="C,15,0,5,0,0"/> <register from="CP15_0_C5_C0_1_MMU" to="C,15,0,5,0,1"/> <register from="CP15_0_C6_C0_0_MMU" to="C,15,0,6,0,0"/> <register from="CP15_0_C6_C0_0_MPU" to="C,15,0,6,0,0"/> </core> <!-- AARON SNIPPED A WHOLE LOT OF STUFF OUT HERE --> </transport>