Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: gdb-patches@sources.redhat.com, carlton@math.stanford.edu
Subject: PATCH: gdb/709, C++ static members
Date: Wed, 18 Sep 2002 08:40:00 -0000	[thread overview]
Message-ID: <20020918154026.GA24749@nevyn.them.org> (raw)

David, your earlier patch:

        * values.c (value_static_field): Treat an unresolved location the
        same as a nonexistent symbol.  Fix PR gdb/635.

pointed me in the right direction for this fix.  As you may have pointed out
at the time, read_var_value does basically the same thing your fix does in
that case.  It turns out that there's some other cases - this particular one
was LOC_CONST_BYTES - where read_var_value does the right thing and
value_static_field doesn't.  So I just had value_static_field call
read_var_value, which fixes your testcase and also a new one I'll post later
for gdb/709.

Committed, since static members are a C++ thing.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2002-09-18  Daniel Jacobowitz  <drow@mvista.com>

	Fix PR gdb/709
	* values.c (value_static_field): Call read_var_value.

Index: values.c
===================================================================
RCS file: /cvs/src/src/gdb/values.c,v
retrieving revision 1.40
diff -u -p -r1.40 values.c
--- values.c	24 Aug 2002 00:21:35 -0000	1.40
+++ values.c	18 Sep 2002 15:23:14 -0000
@@ -800,25 +800,19 @@ unpack_pointer (struct type *type, char 
 struct value *
 value_static_field (struct type *type, int fieldno)
 {
-  CORE_ADDR addr;
-  asection *sect;
+  struct value *retval;
+
   if (TYPE_FIELD_STATIC_HAS_ADDR (type, fieldno))
     {
-      addr = TYPE_FIELD_STATIC_PHYSADDR (type, fieldno);
-      sect = NULL;
+      retval = value_at (TYPE_FIELD_TYPE (type, fieldno),
+			 TYPE_FIELD_STATIC_PHYSADDR (type, fieldno),
+			 NULL);
     }
   else
     {
       char *phys_name = TYPE_FIELD_STATIC_PHYSNAME (type, fieldno);
       struct symbol *sym = lookup_symbol (phys_name, 0, VAR_NAMESPACE, 0, NULL);
-      /* In some cases (involving uninitalized, unreferenced static
-	 const integral members), g++ -gdwarf-2 can emit debugging
-	 information giving rise to symbols whose SYMBOL_CLASS is
-	 LOC_UNRESOLVED.  In that case, do a minimal symbol lookup.
-	 If it returns a useful value, then the symbol was defined
-	 elsewhere, so we use that information.  Otherwise, return
-	 NULL. */
-      if (sym == NULL || SYMBOL_CLASS (sym) == LOC_UNRESOLVED)
+      if (sym == NULL)
 	{
 	  /* With some compilers, e.g. HP aCC, static data members are reported
 	     as non-debuggable symbols */
@@ -827,27 +821,25 @@ value_static_field (struct type *type, i
 	    return NULL;
 	  else
 	    {
-	      addr = SYMBOL_VALUE_ADDRESS (msym);
-	      sect = SYMBOL_BFD_SECTION (msym);
+	      retval = value_at (TYPE_FIELD_TYPE (type, fieldno),
+				 SYMBOL_VALUE_ADDRESS (msym),
+				 SYMBOL_BFD_SECTION (msym));
 	    }
 	}
       else
 	{
- 	  /* Anything static that isn't a constant, has an address */
- 	  if (SYMBOL_CLASS (sym) != LOC_CONST)
- 	    {
-	      addr = SYMBOL_VALUE_ADDRESS (sym);
-	      sect = SYMBOL_BFD_SECTION (sym);
-	    }
- 	  /* However, static const's do not, the value is already known.  */
- 	  else
- 	    {
- 	      return value_from_longest (TYPE_FIELD_TYPE (type, fieldno), SYMBOL_VALUE (sym));
- 	    }
+	  /* SYM should never have a SYMBOL_CLASS which will require
+	     read_var_value to use the FRAME parameter.  */
+	  if (symbol_read_needs_frame (sym))
+	    warning ("static field's value depends on the current "
+		     "frame - bad debug info?");
+	  retval = read_var_value (sym, NULL);
  	}
-      SET_FIELD_PHYSADDR (TYPE_FIELD (type, fieldno), addr);
+      if (retval && VALUE_LVAL (retval) == lval_memory)
+	SET_FIELD_PHYSADDR (TYPE_FIELD (type, fieldno),
+			    VALUE_ADDRESS (retval));
     }
-  return value_at (TYPE_FIELD_TYPE (type, fieldno), addr, sect);
+  return retval;
 }
 
 /* Change the enclosing type of a value object VAL to NEW_ENCL_TYPE.  


             reply	other threads:[~2002-09-18 15:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-18  8:40 Daniel Jacobowitz [this message]
2002-09-18 10:38 ` David Carlton
2002-09-18 10:55 ` Daniel Jacobowitz

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=20020918154026.GA24749@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=carlton@math.stanford.edu \
    --cc=gdb-patches@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