[commit] Don't call target_store_registers()

[Andrew Cagney <ac131313 at redhat dot com>]

Hello,

The attached removes the target_store_registers() call that was causing 
i386 on FreeBSD grief.

> +  /* We've made right mess of GDB's local state, just discard
> > +     everything.  */
> > +  target_store_registers (-1);
> >    flush_cached_frames ();
> >  }
>
>
> The call to target_store_registers you introduced here, writes back
> all registers, including those registers that weren't in the register
> cache at all.

Missing target_prepare_to_store() perhaphs.  However, per comment I 
added, target_prepare_to_store() doesn't do much helpful.

> As a result, on the i386, this typically makes us write
> bogus values into the floating-point registers.  This makes several
> tests in gdb.base/return2.exp fail on my i386-unknown-freebsd4.7
> system, since executing a floating-point instruction with the thrashed
> floating-point state generates a SIGFPE.  I'd expect to see these same
> failures on i686-pc-linux-gnu, but I assume that was the target you
> tested on.

RH 7.2, NB PPC, I didn't notice failures.

> Therefore I suspect that the Linux kernel doesn't let you
> write to the floating-point registers since the floating-point state
> wasn't initialized yet[1].

Who knows.

> Moving the call to target_store_registers() call into the
> !POP_FRAME_P() block solves the problem.  Do you agree that's the
> right approach?

I deleted it.  The d10v doesn't need it and that is the only target that 
so far uses that data path.

I think, in the past, this has been handled using 
target_prepare_to_store() + target_store_registers(-1).

> [1] Initialization of the floating-point state usually happens in a
> "lazy" fashion on most i386 OS'es, i.e. upon execution of the first
> floating-point rinstruction.

Andrew



2003-03-16  Andrew Cagney  <cagney at redhat dot com>

	* frame.c (frame_pop): Don't call target_store_registers.  Fix
	problem reported by Mark Kettenis.

Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.85
diff -u -r1.85 frame.c
--- frame.c	14 Mar 2003 20:34:14 -0000	1.85
+++ frame.c	16 Mar 2003 20:46:50 -0000
@@ -215,6 +215,14 @@
       struct regcache *scratch = regcache_xmalloc (current_gdbarch);
       struct cleanup *cleanups = make_cleanup_regcache_xfree (scratch);
       regcache_save (scratch, do_frame_unwind_register, this_frame);
+      /* FIXME: cagney/2003-03-16: It should be possible to tell the
+         target's register cache that it is about to be hit with a
+         burst register transfer and that the sequence of register
+         writes should be batched.  The pair target_prepare_to_store()
+         and target_store_registers() kind of suggest this
+         functionality.  Unfortunatly, they don't implement it.  Their
+         lack of a formal definition can lead to targets writing back
+         bogus values (arguably a bug in the target code mind).  */
       /* Now copy those saved registers into the current regcache.
          Here, regcache_cpy() calls regcache_restore().  */
       regcache_cpy (current_regcache, scratch);
@@ -222,7 +230,6 @@
     }
   /* We've made right mess of GDB's local state, just discard
      everything.  */
-  target_store_registers (-1);
   flush_cached_frames ();
 }