Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Subject: Re: [RFA] Enhance stabs reader to better deal with forward references
Date: Wed, 28 Feb 2007 20:12:00 -0000	[thread overview]
Message-ID: <20070228201201.GH13140@adacore.com> (raw)
In-Reply-To: <20070227165003.GB31729@caradoc.them.org>

[-- Attachment #1: Type: text/plain, Size: 1851 bytes --]

> > That's why I modified this part of the code to make the cv type
> > only when the target type was already defined. Otherwise, we give
> > up the "const" qualifier and reuse the target type instead. We
> > know that this target type will be fixed up later, so our parameter
> > will have a defined type, and we'll be able to print it. We end up
> > losing the "const" qualifier, but this is still way better than
> > not having any type at all.
> 
> I really don't like this part.  I don't understand it, either.  Why is
> the CV type complete?  When the non-qualified type is filled in, that
> should automatically fill this in, because of the CV ring.  See the
> implementation of replace_type.

You were right. This is unnecessary. Once I applied the fix to replace_type
(see http://www.sourceware.org/ml/gdb-patches/2007-02/msg00384.html),
I was able to remove this change and still get the proper result.

So here is a new submission of the rest of the changes, left untouched
since the last submission.

2007-02-08  Joel Brobecker  <brobecker@adacore.com>

        * stabsread.c (add_undefined_type): Add extra parameter.
        Now handles nameless types separately.
        (struct nat): New type.
        (noname_undefs, noname_undefs_allocated, noname_undefs_length):
        New static variables.
        (read_type): Update calls to add_undefined_type.
        (add_undefined_type_noname): New function.
        (add_undefined_type_1): Renames from add_undefined_type.
        (cleanup_undefined_types_noname): New function.
        (cleanup_undefined_types_1): Renames cleanup_undefined_types.
        (cleanup_undefined_types): New handles nameless types separately.
        (_initialize_stabsread): Initialize our new static constants.

The following patch has been tested on x86-linux with -gstabs+.
OK to apply?

Thanks,
-- 
Joel

[-- Attachment #2: stabsread.c.diff --]
[-- Type: text/plain, Size: 5670 bytes --]

Index: stabsread.c
===================================================================
RCS file: /cvs/src/src/gdb/stabsread.c,v
retrieving revision 1.87
diff -u -p -r1.87 stabsread.c
--- stabsread.c	28 Feb 2007 05:59:14 -0000	1.87
+++ stabsread.c	28 Feb 2007 20:06:50 -0000
@@ -147,7 +147,7 @@ static struct type *read_array_type (cha
 
 static struct field *read_args (char **, int, struct objfile *, int *, int *);
 
-static void add_undefined_type (struct type *);
+static void add_undefined_type (struct type *, int[2]);
 
 static int
 read_cpp_abbrev (struct field_info *, char **, struct type *,
@@ -198,6 +198,20 @@ static int undef_types_allocated;
 static int undef_types_length;
 static struct symbol *current_symbol = NULL;
 
+/* Make a list of nameless type that are undefined.
+   This happens when another type is referenced by its number
+   before this type is actually defined. For instance "t(0,1)=k(0,2)"
+   and type (0,2) is defined only later.  */
+
+struct nat
+{
+  int typenums[2];
+  struct type *type;
+};
+static struct nat *noname_undefs;
+static int noname_undefs_allocated;
+static int noname_undefs_length;
+
 /* Check for and handle cretinous stabs symbol name continuation!  */
 #define STABS_CONTINUE(pp,objfile)				\
   do {							\
@@ -1447,7 +1461,7 @@ read_type (char **pp, struct objfile *ob
              doesn't get patched up by the time we're done
              reading.  */
           if (TYPE_CODE (type) == TYPE_CODE_UNDEF)
-            add_undefined_type (type);
+            add_undefined_type (type, typenums);
 
           return type;
         }
@@ -1573,7 +1587,7 @@ again:
 	INIT_CPLUS_SPECIFIC (type);
 	TYPE_FLAGS (type) |= TYPE_FLAG_STUB;
 
-	add_undefined_type (type);
+	add_undefined_type (type, typenums);
 	return type;
       }
 
@@ -4170,13 +4184,33 @@ fix_common_block (struct symbol *sym, in
 \f
 
 
-/* What about types defined as forward references inside of a small lexical
-   scope?  */
-/* Add a type to the list of undefined types to be checked through
-   once this file has been read in.  */
+/* Add {TYPE, TYPENUMS} to the NONAME_UNDEFS vector.
+   See add_undefined_type for more details.  */
 
 static void
-add_undefined_type (struct type *type)
+add_undefined_type_noname (struct type *type, int typenums[2])
+{
+  struct nat nat;
+
+  nat.typenums[0] = typenums [0];
+  nat.typenums[1] = typenums [1];
+  nat.type = type;
+
+  if (noname_undefs_length == noname_undefs_allocated)
+    {
+      noname_undefs_allocated *= 2;
+      noname_undefs = (struct nat *)
+	xrealloc ((char *) noname_undefs,
+		  noname_undefs_allocated * sizeof (struct nat));
+    }
+  noname_undefs[noname_undefs_length++] = nat;
+}
+
+/* Add TYPE to the UNDEF_TYPES vector.
+   See add_undefined_type for more details.  */
+
+static void
+add_undefined_type_1 (struct type *type)
 {
   if (undef_types_length == undef_types_allocated)
     {
@@ -4188,6 +4222,48 @@ add_undefined_type (struct type *type)
   undef_types[undef_types_length++] = type;
 }
 
+/* What about types defined as forward references inside of a small lexical
+   scope?  */
+/* Add a type to the list of undefined types to be checked through
+   once this file has been read in.
+   
+   In practice, we actually maintain two such list: The first list
+   (UNDEF_TYPES) is used for types whose name has been provided, and
+   concerns forward references (eg 'xs' or 'xu' forward references);
+   the second list (NONAME_UNDEFS) is used for types whose name is
+   unknown at creation time, because they were referenced through
+   their type number before the actual type was declared.
+   This function actually adds the given type to the proper list.  */
+
+static void
+add_undefined_type (struct type *type, int typenums[2])
+{
+  if (TYPE_TAG_NAME (type) == NULL)
+    add_undefined_type_noname (type, typenums);
+  else
+    add_undefined_type_1 (type);
+}
+
+/* Try to fix all undefined types pushed on the UNDEF_TYPES vector.  */
+
+void
+cleanup_undefined_types_noname (void)
+{
+  int i;
+
+  for (i = 0; i < noname_undefs_length; i++)
+    {
+      struct nat nat = noname_undefs[i];
+      struct type **type;
+
+      type = dbx_lookup_type (nat.typenums);
+      if (nat.type != *type && TYPE_CODE (*type) != TYPE_CODE_UNDEF)
+        replace_type (nat.type, *type);
+    }
+
+  noname_undefs_length = 0;
+}
+
 /* Go through each undefined type, see if it's still undefined, and fix it
    up if possible.  We have two kinds of undefined types:
 
@@ -4197,8 +4273,9 @@ add_undefined_type (struct type *type)
    TYPE_CODE_STRUCT, TYPE_CODE_UNION:  Structure whose fields were not
    yet defined at the time a pointer to it was made.
    Fix:  Do a full lookup on the struct/union tag.  */
+
 void
-cleanup_undefined_types (void)
+cleanup_undefined_types_1 (void)
 {
   struct type **type;
 
@@ -4259,6 +4336,16 @@ cleanup_undefined_types (void)
   undef_types_length = 0;
 }
 
+/* Try to fix all the undefined types we ecountered while processing
+   this unit.  */
+
+void
+cleanup_undefined_types (void)
+{
+  cleanup_undefined_types_1 ();
+  cleanup_undefined_types_noname ();
+}
+
 /* Scan through all of the global symbols defined in the object file,
    assigning values to the debugging symbols that need to be assigned
    to.  Get these symbols from the minimal symbol table.  */
@@ -4494,4 +4581,9 @@ _initialize_stabsread (void)
   undef_types_length = 0;
   undef_types = (struct type **)
     xmalloc (undef_types_allocated * sizeof (struct type *));
+
+  noname_undefs_allocated = 20;
+  noname_undefs_length = 0;
+  noname_undefs = (struct nat *)
+    xmalloc (noname_undefs_allocated * sizeof (struct nat));
 }

  parent reply	other threads:[~2007-02-28 20:12 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-09 19:40 Joel Brobecker
2007-02-27 16:50 ` Daniel Jacobowitz
2007-02-28  5:48   ` Joel Brobecker
2007-02-28 11:42     ` Daniel Jacobowitz
2007-02-28 20:12   ` Joel Brobecker [this message]
2007-03-27 16:29     ` Daniel Jacobowitz
2007-03-29 18:35       ` Joel Brobecker
2007-03-31 20:42         ` Pedro Alves
2007-04-02  6:59           ` Joel Brobecker
2007-04-02  8:51             ` Pierre Muller
2007-04-02 11:05           ` Daniel Jacobowitz
2007-04-03  0:13             ` Pedro Alves
2007-04-03  3:50               ` Christopher Faylor

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=20070228201201.GH13140@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /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