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