How do I replace DEPRECATED_TM_FILE?

How do I replace DEPRECATED_TM_FILE?

[Joern Rennecke]

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?

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
files.
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.

Re: How do I replace DEPRECATED_TM_FILE?

[Daniel Jacobowitz]

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
vector (target_ops).

> 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
> files.
> 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.

-- 
Daniel Jacobowitz
CodeSourcery

Re: How do I replace DEPRECATED_TM_FILE?

[Joern Rennecke]

> Why are the register numbers different (and which register numbers)?

It's because of the different dwarf mapping.
These are the registers that are different in linux that for the plain
embedded target:

enum arc700_linux_regnums
  {
    /* Regnums 0..26 are R0..R26 */
    ARC_BTA_REGNUM      =       27,
    ARC_LP_START_REGNUM =       28,
    ARC_LP_END_REGNUM   =       29,
    ARC_LP_COUNT_REGNUM =       30,
    ARC_STATUS32_REGNUM =       31,
    ARC_BLINK_REGNUM    =       32,
    ARC_FP_REGNUM       =       33,
    ARC_SP_REGNUM       =       34,
    ARC_EFA_REGNUM      =       35,
    ARC_RET_REGNUM      =       36,
    ARC_ORIG_R8_REGNUM  =       37,
    ARC_STOP_PC_REGNUM  =       38
  };

#define ARC_NR_REGS     39

/* Pseudo-regs.  */
#define ARC_ILINK1_REGNUM       (NUM_REGS)
#define ARC_ILINK2_REGNUM       (NUM_REGS+1)
#define ARC_ERET_REGNUM         (NUM_REGS+2)
#define ARC_STATUS32_L1_REGNUM  (NUM_REGS+3)
#define ARC_STATUS32_L2_REGNUM  (NUM_REGS+4)
#define ARC_ERSTATUS_REGNUM     (NUM_REGS+5)

except for ARC_RET_REGNUM and ARC_ORIG_R8_REGNUM, these registers
exist also for the embedded target, but with different numbers;
the embedded target allos access to numerous extra auxilary registers.

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

Another difference is the osabi setting.  arc_gdbarch_init also calls
different functions for the different subtargtes to set a number of other
settings.

Re: How do I replace DEPRECATED_TM_FILE?

[Daniel Jacobowitz]

On Thu, Jun 21, 2007 at 06:33:42PM +0100, Joern Rennecke wrote:
> except for ARC_RET_REGNUM and ARC_ORIG_R8_REGNUM, these registers
> exist also for the embedded target, but with different numbers;
> the embedded target allos access to numerous extra auxilary registers.

Which registers are available to talk to is a property of the target;
you might want to look at target descriptions, which have been my
project for the last year or two.  Which ones a DWARF number refers to
are a gdbarch property.

> > 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.
> 
> Another difference is the osabi setting.  arc_gdbarch_init also calls
> different functions for the different subtargtes to set a number of other
> settings.

No, I mean, you use the OSABI setting to determine which set of dwarf
registers you mean.  I don't know what you meant by "another
difference is the OSABI setting"; you should not be setting the OSABI
in your arc_gdbarch_init, you should be using the normal sniffers and
letting gdbarch_init_osabi dispatch appropriately.

-- 
Daniel Jacobowitz
CodeSourcery

Re: How do I replace DEPRECATED_TM_FILE?

[Joern Rennecke]

On Thu, Jun 21, 2007 at 12:21:52PM -0400, Daniel Jacobowitz wrote:
> 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 did some more digging, and found that apparently the dwarf register numbers
start out the same, but they are translated with dwarf_reg_to_regno functions
to be different.

As far as I can tell, the problem stems from gdbserver coupling the
target communication directly with the register cache.
The register numbers that arc-linux uses are different than the hardware and
the dwarf register numbers.  Moreover, some registers are not accessible, and
some values appear as registers that actually give a view of some of the data
that is not direcly accessible:
ret, orig_r8 and stop_pc.
Two of the registers that are not directly accessible are ilink1 and ilink2,
which contain the return from interrupt address for interrupts of level 1 and
level 2, respectively.
Linux saves only the return address for the previous frame, e.g. for a level
1 interrupt, it will save ilink1 in ret, and set orig_r8 to -1 to indicate
that that is what is in ret.

I suppose it could make sense to try to make the linux target look more like
the hardware to the gdb user, by translating these values the best we can,
but I don't see how this can be done with gdbserver; linux-low.c seems
to assume that the linux register set and numbering must be exactly what the
gdb user sees.
I must admit I don't think I understand gdbserver very well yet;
is there any overview of the gdbserver internals like gdbint.texinfo for
the rest of gdb?  Although it took me quite a while to read through that
document, it left me with a better understanding (I hope) of how things
are supposed to fit together in gdb (although I had to resort to grep
to confirm that (and findout why) the _initialize_* functions are 'magic').