This is the mail archive of the gdb-cvs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gdb and binutils branch master updated. 2b0f535a446c682c3dc7c1276e2cbc747bfae163


This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  2b0f535a446c682c3dc7c1276e2cbc747bfae163 (commit)
      from  8908fca5772fcff9f7766158ba2aa59f5a2b1f68 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2b0f535a446c682c3dc7c1276e2cbc747bfae163

commit 2b0f535a446c682c3dc7c1276e2cbc747bfae163
Author: Joel Brobecker <brobecker@adacore.com>
Date:   Tue Oct 7 02:22:21 2014 +0200

    [Ada] gdb.ada/complete.exp failure on x86_64-windows
    
    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.

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog  |    5 +++++
 gdb/ada-lang.c |   12 ++++++++++--
 2 files changed, 15 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
gdb and binutils


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]