Register cache

[Mark Kettenis <kettenis@wins.uva.nl>]

A few days ago Eli proposed the following patch:

   http://sources.redhat.com/ml/gdb-patches/2001-02/msg00140.html

It proposes a new interface to supply a single i387 register to GDB's
internal register cache in addition to the existing interface that
supplies the whole FPU state.

In a perhaps overly pedantic mood, I raised some objections to the
patch.  I would prefer not to add yet another interface, and I
suggested to Eli that he'd simply use the existing interface, to which
he responded that that would implicate violating the
target_fetch_registers() API.  Let me explain:

We have the following comment on target_fetch_registers() in target.h:

   /* Fetch register REGNO, or all regs if regno == -1.  No result.  */

This suggests that target_fetch_registers() will fetch exactly one
register if REGNO != -1.  However, quite a few targets do something
different, that is, they fetch at least register REGNO, but actually
fetch a whole bunch of them.  This probably started with SVR4-ish
systems that have a /proc filesystem.  On those systems it isn't
possible to fetch a single register.  Instead one get a whole bunch
and procfs_fetch_registers() supplies them all to GDB's register
cache.  Comments in procfs.c suggest that this is an optimization; by
caching the whole register set on possibly saves a few system calls in
the future.  Other targets like the modern BSDs and GNU/Linux that
have appropriate ptrace() requests followed this example and do the
same thing.

Is this really a good idea?  I think it is, at least on targets where
getting at the registers is relatively expensive since it involves a
system call.  Therefore I propose to make this "official" and change
the comment on target_fetch_registers() to:

   /* Fetch at least register REGNO, or all regs if REGNO == -1.  */

Another question is whether we should make this behaviour (I mean
having target_fetch_registers() supply all registers it managed to get
in one go) recommended practice.

Mark