Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@chello.nl>
To: ac131313@redhat.com
Cc: drow@mvista.com, gdb@sources.redhat.com
Subject: Re: RFC: Variables in blocks of registers
Date: Sun, 02 Feb 2003 16:13:00 -0000	[thread overview]
Message-ID: <200302012235.h11MZ30D023842@elgar.kettenis.dyndns.org> (raw)
In-Reply-To: <3E3C3200.8070803@redhat.com> (message from Andrew Cagney on Sat, 01 Feb 2003 15:45:52 -0500)

   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);



  reply	other threads:[~2003-02-02 16:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-01 14:48 Mark Kettenis
2003-02-01 15:48 ` Andrew Cagney
2003-02-01 17:09   ` Daniel Jacobowitz
2003-02-01 20:45     ` Andrew Cagney
2003-02-02 16:13       ` Mark Kettenis [this message]
2003-02-02  5:21         ` Daniel Jacobowitz
2003-02-02 16:52         ` Andrew Cagney
2003-02-02 16:27           ` Daniel Jacobowitz
2003-02-04  2:31       ` Jim Blandy
2003-02-04  4:07         ` Daniel Berlin
2003-02-02 15:33     ` Daniel Berlin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200302012235.h11MZ30D023842@elgar.kettenis.dyndns.org \
    --to=kettenis@chello.nl \
    --cc=ac131313@redhat.com \
    --cc=drow@mvista.com \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox