This is the mail archive of the
mailing list for the GDB project.
Re: How do I replace DEPRECATED_TM_FILE?
- From: Daniel Jacobowitz <drow at false dot org>
- To: Joern Rennecke <joernr at arc dot com>
- Cc: gdb at sourceware dot org
- Date: Thu, 21 Jun 2007 12:21:52 -0400
- Subject: Re: How do I replace DEPRECATED_TM_FILE?
- References: <20070621161305.GD8169@elsdt-razorfish.arc.com>
On Thu, Jun 21, 2007 at 05:13:05PM +0100, Joern Rennecke wrote:
> I've read that instead of setting DEPRECATED_TM_FILE, we should add new
> members to the target vector. However, how is the target vector supposed to
> be initialized differently for different subtargets?
The architecture vector (gdbarch), usually, but sometimes the target
> E.g. arc700 can both be used in an 'embedded' configuration and as a linux
> target. The register numbers in gdb are different for these configurations.
> The register numbers used to be defined in separate DEPRECATED_TM_FILE
> I can add xxx_regnum members to the target vector and ARC_XX_REGNUM
> accessor macros, but somehow I have to decide in arc_gdbarch_init how I am
> supposed to initialize the target vector.
Why are the register numbers different (and which register numbers)?
That determines the answer to your question. If it's the dwarf2
mapping, for instance, you'd put overrides in an OS/ABI sniffer in the
Linux tdep file.
I've done a lot of work lately to isolate GDB's internal register
numbering from various external numberings. You can probably use the
same internal registers in most places now.