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

[Kevin Buettner <kevinb@redhat.com>]

On Nov 29,  5:56pm, Andrew Cagney wrote:
> > On Nov 29,  4:45pm, Andrew Cagney wrote:
> > 
> >> I suspect a few more targets could do with the same treatment. 
> >> Eliminating that hardwired regmap[] would probably help a few more targets.
> > 
> > Perhaps.  But, I think each target better have good reasons for doing
> > so before undertaking such a transformation.  Replacing the hardwired
> > regmap[] with a function with the same constants hardwired into it
> > doesn't accomplish much (aside from slowing things somewhat).
> 
> The problem is, they are not constant.  Because of limitations in the 
> way other parts of GDB currently work, an architecture change can cause 
> those offsets to change :-(  Check x86-64 vs i386.

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.

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];
}

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.

Kevin