Handle type-casting in template parameter list when hashing symbols

Due to a logical bug in gdb/cp-support.c:cp_search_name_hash(), GDB
may not be able to find a symbol when asked by the user.  See the
accompanying test for such demonstration.

The cp_search_name_hash() cannot correctly handle a (demangled) symbol
that comprises of type-casting for the first parameter in its template
parameter list, e.g.:

  foo<(enum_test)0>(int, int)

In this example, the processing logic in cp_search_name_hash() considers
the "foo<" string for hashing instead of "foo".  This is due to a faulty
logic in the processing loop that tries to _keep_ hashing if a '<' char
with the following property is encountered:

---------------------------------------------------------------------
for (const char *string = search_name; *string != '\0'; ++string)
  {
    ...

    if (*string == '(')
      break;

    ...

    /* Ignore template parameter list.  */
    if (string[0] == '<'
        && string[1] != '(' && string[1] != '<' && string[1] != '='
        && string[1] != ' ' && string[1] = '\0')
      break;

    ...
    hash = SYMBOL_HASH_NEXT (hash, *string);
  }
---------------------------------------------------------------------

Ostensibly, this logic strives to bail out of the processing loop as
soon as the beginning of an argument list is encountered, "(int, int)"
in the example, or the beginning of a template parameter list, the
"<(enum_test)0>" in the example.  However, when "string" is pointing
at '<', the following incorrect logic takes precedence:

---------------------------------------------------------------------
for (const char *string = search_name; *string != '\0'; ++string)
  {
    if (*string == '(')
      break;
    ...
    if (string[0] == '<' && string[1] != '(' ...)
      break;

    hash = SYMBOL_HASH_NEXT (hash, *string);
  }
---------------------------------------------------------------------

In "foo<(enum_test)0>(int, int)", the '(' char that is positioned after
the '<' char causes the "if" condition at the end of the loop not to
"break".  As a result, the '<' is considered for hashing and at the
beginning of the next iteration, the loop is exited because "string"
points to '(' char.

It's obvious that the intention of the "if" condition at the end of the
loop body is to handle cases where the method name is "operator<",
"operator<<", or "operator<=".  While fixing the issue, I've re-written
the logic as such to make that more explicit.  Still, the complexity of
the function remains O(n).  It is worth mentioning that in the same
file the "find_toplevel_char()" follows the same explicit logic.

Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
Reviewed-By: Pedro Alves <pedro@palves.net>
Approved-by: Tom Tromey <tom@tromey.com>
Change-Id: I64cbdbe79671e070cc5da465d1cce7989c58074e

0 files changed, 0 insertions, 0 deletions