Re: [RFA] ppc-linux-nat.c: Don't use regmap[] anymore.

[Andrew Cagney <ac131313 at cygnus dot com>]

> 
> Just to make sure we're talking about the same thing...  regmap[] maps
> GDB register numbers to ``struct user'' offsets.  These are used when
> calling ptrace() and are sometimes used for obtaining struct offsets
> within a gregset.

Yes, a given nat file will use constant offsets to find a given register 
in the ptrace / corefile / ....  The ``regnum'' assigned to that 
register, however, can change.

> I don't know much about Linux/x86-64, but I would imagine that its
> ``struct user'' is different than that used for Linux/x86.  (Which, I
> gather, is what you mean by these offsets not being constant.)  If it's
> somehow possible to debug Linux/x86 programs on Linux/x86-64, then we
> would indeed need a mechanism to pick the right regmap[].  Certainly,
> using a function in this case would make sense.  However, it might
> well be implemented something like this:
> 
> static int
> regmap (int regno)
> {
>   static int x86_regmap[] = { ... };
>   static int x86_64_regmap[] = { ... };
>   if (target_is_x86_64 ())
>     return x86_64_regmap[regno];
>   else
>     return x86_regmap[regno];
> }

Yes.  This would handle two of the possible REGNUM -> OFFSET mappings. 
I think a more robust way of doing it is:

	if (regnum in I386_FP0_REGNUM to MAX)
	  DO SOMETHING;
	else if regnum in someother register range;
	  do something else;

which means you're insulated from a problem such as the regnum's being 
re-aranged (Hmm, lets slip MMX registers in between FP and XMM registers).

> I did look at x86-64-linux-nat.c and it does appear to be amazingly
> similar to i386-linux-nat.c.  It would be nice if the same file could
> be used for both architectures.  If making a more dynamic regmap[]
> is what's needed, then I'm all for it.

I suspect Mark K has thoughts of doing that :-)

There are other ways this could be handled, however, for the moment I 
think the run-time test is safest.  I'm getting ready to post a really 
nasty regcache.[hc] patch that will hopefully illustrate one of the 
problems - NUM_REGS and REGISTER_BYTES.

enjoy,
Andrew