Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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


-----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
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)


Aaron Spear
Debug Tools Architect/Staff Engineer
Mentor Graphics

dsdp-dd-dev mailing list

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">
<!-- ******************** REGISTER MAPPINGS ***********************************

	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.

		<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"/>

Back to the top