This is the mail archive of the gdb@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]

Re: RFC: Variables in blocks of registers


   Date: Sat, 01 Feb 2003 15:45:52 -0500
   From: Andrew Cagney <ac131313@redhat.com>

   > Michael, I think the new multi-arch function is a good idea as long as
   > it is a fallback from explicit debug info support, when we have such. 
   > I also think it needs a better name; but I'm not quite sure what.  Hmm,
   > that could be mitigated by adequate commenting.

I suppose Daniel meant me, Mark, here ;-).

   I think it is very dangerous.  It's assuming a specific algorithm
   in the compiler.  That locks both GDB and GCC into something of a
   death spiral.  I think its far better to try and get a proper
   location mechanism working.

Hmm, I agree that it is better to get a proper location mechanism
working.  However, I don't think we have any hope at getting such a
mechanism working with stabs.  And I don't agree that it is very
dangerous to assume the specific algorithm that GCC has been using for
several years.  Besides GDB already uses a specific algorithm since it
assumes that registers have been allocated by the compiler in the
order that is dictated by GDB's register cache.  That algorithm is
known to be wrong for the majority of GDB's users, makes GDB print
bugus values and can lead to segfaults in the inferior when setting
variables.  Why not replace this algorithm with something better?  The
changes that are necessary aren't very invasive (see the end of this
message for the changes to findvar.c and valops.c).

Daniel, do you think next_allocated_regnum is a better name?

Mark

Index: findvar.c
===================================================================
RCS file: /cvs/src/src/gdb/findvar.c,v
retrieving revision 1.44
diff -u -p -r1.44 findvar.c
--- findvar.c 14 Jan 2003 00:49:03 -0000 1.44
+++ findvar.c 1 Feb 2003 22:29:45 -0000
@@ -753,17 +753,18 @@ value_from_register (struct type *type, 
 	for (local_regnum = regnum;
 	     value_bytes_copied < len;
 	     (value_bytes_copied += REGISTER_RAW_SIZE (local_regnum),
-	      ++local_regnum))
+	      local_regnum = gdbarch_next_allocated_regnum (current_gdbarch,
+							    local_regnum)))
 	  {
+	    if (local_regnum == -1)
+	      return NULL;	/* Register unknown.  */
+
 	    get_saved_register (value_bytes + value_bytes_copied,
-				&optim,
-				&addr,
-				frame,
-				local_regnum,
+				&optim, &addr, frame, local_regnum,
 				&lval);
 
Index: valops.c
===================================================================
RCS file: /cvs/src/src/gdb/valops.c,v
retrieving revision 1.89
diff -u -p -r1.89 valops.c
--- valops.c 30 Jan 2003 16:44:20 -0000 1.89
+++ valops.c 1 Feb 2003 22:29:47 -0000
@@ -704,13 +704,17 @@ value_assign (struct value *toval, struc
 	/* Copy it out.  */
 	for (regno = reg_offset, amount_copied = 0;
 	     amount_copied < amount_to_copy;
-	     amount_copied += REGISTER_RAW_SIZE (regno), regno++)
+	     (amount_copied += REGISTER_RAW_SIZE (regno),
+	      regno = gdbarch_next_allocated_regnum (current_gdbarch, regno)))
 	  {
 	    enum lval_type lval;
 	    CORE_ADDR addr;
 	    int optim;
 	    int realnum;
-	    
+
+	    if (regno == -1)
+	      error ("Location of variable is unknown.");
+
 	    /* Just find out where to put it.  */
 	    frame_register (frame, regno, &optim, &lval, &addr, &realnum,
 			    NULL);



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