Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: brobecker@adacore.com, gdb-patches@sourceware.org
Subject: [rfa/Ada] Remove builtin_type_void
Date: Fri, 26 Jun 2009 15:53:00 -0000	[thread overview]
Message-ID: <200906261553.n5QFrkps030405@d12av02.megacenter.de.ibm.com> (raw)

Hello Joel,

this patch removes references to builtin_type_void from Ada code.

The only nontrivial case is the use in ada_resolve_function.  This routine
is called with "context_type" either NULL or a void type on input.  It
implements a two-phase search, where in the first phase it accepts all
routine with matching return type:

   If CONTEXT_TYPE is non-null and there is at least one match
   that returns that type, then eliminate matches that don't.  If
   CONTEXT_TYPE is void and there is at least one match that does not
   return void, eliminate all matches that do.

If no match is found during the first phase, it performs a second
phase with an "inverted" value of context_type: if it was a void type,
it becomes NULL, and if it was NULL, it becomes builtin_type_void.

My patch simplifies this by having the second phase simply accept
*all* matches.  There is no need to "invert" context_type -- we
already know that there are no matches for context_type, so any
remaining match is OK to return.

Tested on amd64-linux.  OK for mainline?

Bye,
Ulrich


ChangeLog:

	* ada-lang.c (resolve): Use per-architecture void type instead
	of platform-independent one.
	(ada_evaluate_subexp) [STRUCTOP_STRUCT]: Likewise.
	(ada_resolve_function): Reimplement fallback logic to avoid
	explicit reference to builtin_type_void.

Index: gdb-head/gdb/ada-lang.c
===================================================================
--- gdb-head.orig/gdb/ada-lang.c
+++ gdb-head/gdb/ada-lang.c
@@ -2583,9 +2583,13 @@ ada_decoded_op_name (enum exp_opcode op)
 static void
 resolve (struct expression **expp, int void_context_p)
 {
-  int pc;
-  pc = 0;
-  resolve_subexp (expp, &pc, 1, void_context_p ? builtin_type_void : NULL);
+  struct type *context_type = NULL;
+  int pc = 0;
+
+  if (void_context_p)
+    context_type = builtin_type ((*expp)->gdbarch)->builtin_void;
+
+  resolve_subexp (expp, &pc, 1, context_type);
 }
 
 /* Resolve the operator of the subexpression beginning at
@@ -3091,35 +3095,27 @@ ada_resolve_function (struct ada_symbol_
                       int nsyms, struct value **args, int nargs,
                       const char *name, struct type *context_type)
 {
+  int fallback;
   int k;
   int m;                        /* Number of hits */
-  struct type *fallback;
-  struct type *return_type;
-
-  return_type = context_type;
-  if (context_type == NULL)
-    fallback = builtin_type_void;
-  else
-    fallback = NULL;
 
   m = 0;
-  while (1)
+  /* In the first pass of the loop, we only accept functions matching
+     context_type.  If none are found, we add a second pass of the loop
+     where every function is accepted.  */
+  for (fallback = 0; m == 0 && fallback < 2; fallback++)
     {
       for (k = 0; k < nsyms; k += 1)
         {
           struct type *type = ada_check_typedef (SYMBOL_TYPE (syms[k].sym));
 
           if (ada_args_match (syms[k].sym, args, nargs)
-              && return_match (type, return_type))
+              && (fallback || return_match (type, context_type)))
             {
               syms[m] = syms[k];
               m += 1;
             }
         }
-      if (m > 0 || return_type == fallback)
-        break;
-      else
-        return_type = fallback;
     }
 
   if (m == 0)
@@ -9372,7 +9368,8 @@ ada_evaluate_subexp (struct type *expect
                    in some extension of the type.  Return an object of 
                    "type" void, which will match any formal 
                    (see ada_type_match). */
-                return value_zero (builtin_type_void, lval_memory);
+                return value_zero (builtin_type (exp->gdbarch)->builtin_void,
+				   lval_memory);
             }
           else
             type =
-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


             reply	other threads:[~2009-06-26 15:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-26 15:53 Ulrich Weigand [this message]
2009-06-29 15:39 ` Joel Brobecker
2009-06-29 17:32   ` Ulrich Weigand

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=200906261553.n5QFrkps030405@d12av02.megacenter.de.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=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