This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

frame_pop(); Was: [commit] 32 bit MIPS fixes for dummy frames


Hello,

This patch fixes two problems with the 32 bit MIPS handling dummy frames:

- even when it fluked a hit, the pop would barf as it de-referenced an uninitialized variable (the mips register unwinder isn't yet in good enough shape to allow the deletion of mips_pop_frame :-().

I got a question on this, so to expand a little:


The new frame unwind code doesn't have a per-architecture frame_pop() method, instead it relies on the correctness of the per-frame register unwind. For instance, looking at the old style mips_pop_frame(), there is the line:

write_register (PC_REGNUM, DEPRECATED_FRAME_SAVED_PC (frame));

so it is relying on a custom PC unwind. The new code instead just assumes that the PC register's value can be unwound/popped using a sequence like (I've appended a snipit of the code):

	frame_register_unwind (frame, PC_REGNUM, buf);
	regcache_cooked_write (current_regcache, PC_REGNUM, buf);

Since existing targets have never had good reason to correctly unwind the PC, they will most likely get it wrong.

Andrew

    {
      /* Make a copy of all the register values unwound from this
         frame.  Save them in a scratch buffer so that there isn't a
         race betweening trying to extract the old values from the
         current_regcache while, at the same time writing new values
         into that same cache.  */
      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);
      do_cleanups (cleanups);
    }



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]