This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] ppc-linux-nat.c: Don't use regmap[] anymore.
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