Re: [RFA]: New function to supply only one x87 register

[Mark Kettenis <kettenis at wins dot uva dot nl>]

   Date: Sat, 10 Feb 2001 06:42:14 -0500 (EST)
   From: Eli Zaretskii <eliz@delorie.com>

   > Date: Fri, 9 Feb 2001 17:55:15 +0100 (MET)
   > From: Mark Kettenis <kettenis@wins.uva.nl>
   > 
   >    I don't know enough about GDB's register cache to feel safe with such
   >    assumptions.  What I'm trying to do is be consistent with the
   >    documented API.  Since target.h's `to_fetch_registers' method says
   >    "fetch register REGNO, or all regs if regno == -1", I'm trying to do
   >    just that and nothing else.
   > 
   >    Isn't it dangerous to have functions in the infrastructure with
   >    built-in implicit assumptions that are not documented anywhere, and
   >    only hold because the current application-level code does what it
   >    does?
   > 
   > Of course it is, but in this particular case it is wide-spread.  All
   > systems with a SVR4-like /proc file system do this, as well as most
   > systems that have a ptrace request that fetches a whole bunch of
   > registers in one go.  By supplying all those registers at once, the
   > cache becomes some sort of read-ahead cache.  This makes sense since
   > GDB hardly ever needs only one register, and pre-fetching those saves
   > a few system calls.  This probably doesn't matter much on go32, but I
   > think you should do it anyway, at least for the FPU.

   I can certainly do that (under a protest! ;-), but it simply seems
   wrong.  I mean, let's take i386bsd-nat.c, for example:

   [...]

   I remember staring at this for a few moments and thinking: this one
   comlpetely ignores REGNO--isn't that a bug? and why does it call
   ptrace for the general registers even if REGNO might be an FP
   register--isn't _that_ a bug??

Calling ptrace for the general registers if REGNO is an FP register
surely isn't very efficient.  It shouldn't hurt, since if it mattered
you'd have cache coherency problems.  So I wouldn't call it a bug (but
hey I wrote that code :-)).

   It simply doesn't feel right to do this sort of things, even if it is
   somehow more efficient.  IMHO, a minor inefficiency is not worth
   circumventing the established API, because it might cost much more in
   maintenance down the road.

True, but this circumvention is so widespread that I'm included to
call it the established API.

   If we think it's a Good Thing to fetch all registers at once, let's
   change the API, or let's have the target end cache them to be more
   efficient (the DJGPP port already does that, btw).

I just posted a message to the discussion list on this subject.  And
no, I don't thing that the target end should cache the registers,
since that would be duplicating what the existing register cache is
already capable of.  I can see why the DJGPP port works the way it
does and caches the registers, but IMHO its way of handling things is
the exception to the way a UNIXoid OS handles this stuff.

   > By supplying all those registers at once, the
   > cache becomes some sort of read-ahead cache.  This makes sense since
   > GDB hardly ever needs only one register, and pre-fetching those saves
   > a few system calls.

   Well, I thought about this, and I'm still not convinced there's a gain
   here, at least not in all possible situations.

There hardly ever is :-(.

   First, if GDB needs more than one FP register, it could just pass -1 as
   REGNO and get them all.

Sure, but that would also re-fetch the generic registers, and the
GNU/Linux/x86 target for example doesn't do that if you request a
single FP register.

   Also, I can certainly think about a situation when GDB actually needs
   only one FP register.  Imagine that I need to put a watchpoint on such
   a register, for example, or display it at each stop.

Yep.  Its a trade off.  And in the DJGPP case there's not much to
gain.  But the cost of supplying those extra registers should be
almost negligable.  I really think that keeping the number of
interfaces down helps the long-time maintainablility of GDB and is
worth that cost.

   Btw, I found only two other platforms which currently use functions
   from i387-nat.c, so it doesn't seem too late to make changes.

True, but I'd really like to keep the symmetry between
supply_fpregset() and i387_supply_fsave() and fill_fpregset() and
i387_fill_fsave().

Mark