[Ada] gdb.ada/complete.exp failure on x86_64-windows
authorJoel Brobecker <brobecker@adacore.com>
Tue, 7 Oct 2014 00:22:21 +0000 (02:22 +0200)
committerJoel Brobecker <brobecker@adacore.com>
Wed, 19 Nov 2014 08:49:55 +0000 (12:49 +0400)
Using the example in gdb.ada/complete.exp, the following command
on x86_64-windows returns one unwanted completion choice :

    (gdb) complete p pck
    p <pck_E>>
    [all following completions entries snipped, all expected]

I tracked down this suprising entry to a minimal symbol whose name
is ".refptr.pck_E". The problem occurs while trying to see if
this symbol matches "pck" when doing wild-matching as we are doing
here:

  /* Second: Try wild matching...  */

  if (!match && wild_match_p)
    {
      /* Since we are doing wild matching, this means that TEXT
         may represent an unqualified symbol name.  We therefore must
         also compare TEXT against the unqualified name of the symbol.  */
      sym_name = ada_unqualified_name (ada_decode (sym_name));
      if (strncmp (sym_name, text, text_len) == 0)
        match = 1;
    }

What happens is that ada_decode correctly identifies the fact that
SYM_NAME (".refptr.pck_E") is not following any GNAT encoding, and
therefore returns that same name, but bracketed: "<.refptr.pck_E>".
This is the convention we use for telling GDB that the decoded name
is not a real Ada name - and therefore should not be encoded for
operations such as name matching, symbol lookups, etc. So far, so good.

Next is the call to ada_unqualified_name, which unfortunately does
not notice that the decoded name it is being given isn't a natural
symbol, and just blindly strips everything up to the last do, returning
"pck_E>". And of course, "pck_E>" matches "pck" now, and so we end
up accepting this symbol as a match.

This patch fixes the problem by making ada_unqualified_name a little
smarter by making sure that the given decoded symbol name does not
start with '<'.

gdb/ChangeLog:

        * ada-lang.c (ada_unqualified_name): Return DECODED_NAME if
        it starts with '<'.

Tested on x86_64-windows using AdaCore's testsuite as well as
on x86_64-linux.

gdb/ChangeLog
gdb/ada-lang.c

index c13c1d491b87bffb25a1fc488d3653d9c3353f62..5f58e6ca4ee0ae76121517882044dd73208f6f31 100644 (file)
@@ -1,3 +1,8 @@
+2014-11-19  Joel Brobecker  <brobecker@adacore.com>
+
+       * ada-lang.c (ada_unqualified_name): Return DECODED_NAME if
+       it starts with '<'.
+
 2014-11-19  Joel Brobecker  <brobecker@adacore.com>
 
        * ada-lang.c (ada_is_redundant_range_encoding): New function.
index 077c29a6099e3c925c318f58e88a5c5c4af259e5..e46ad8e2a057d37b2cdfa8fb3560b457a8a1541c 100644 (file)
@@ -523,8 +523,16 @@ ada_typedef_target_type (struct type *type)
 static const char *
 ada_unqualified_name (const char *decoded_name)
 {
-  const char *result = strrchr (decoded_name, '.');
+  const char *result;
+  
+  /* If the decoded name starts with '<', it means that the encoded
+     name does not follow standard naming conventions, and thus that
+     it is not your typical Ada symbol name.  Trying to unqualify it
+     is therefore pointless and possibly erroneous.  */
+  if (decoded_name[0] == '<')
+    return decoded_name;
 
+  result = strrchr (decoded_name, '.');
   if (result != NULL)
     result++;                   /* Skip the dot...  */
   else