From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15502 invoked by alias); 31 May 2014 01:03:52 -0000 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org Received: (qmail 15157 invoked by uid 48); 31 May 2014 01:03:51 -0000 From: "dje at google dot com" To: gdb-prs@sourceware.org Subject: [Bug c++/17004] print base::operator char * passes in cpexprs.exp, but only accidentally Date: Sat, 31 May 2014 01:03:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: c++ X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dje at google dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-q2/txt/msg00354.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=17004 --- Comment #1 from dje at google dot com --- SamB pointed out on IRC that converting "base::operator char *" to "base::operatorchar *" can be ambiguous if the class also really has a member base::operatorchar. Plus it's not clear to me how much canonicalization is strictly adhered to and how much gdb just gets away with bugs because of how it works. E.g. dwarf2read.c:mapped_index_string_hash doesn't ignore spaces. So if the canonicalization is wrong, the symbol won't be found in the index. However, it probably won't ever matter, at least in the case of member functions, because gdb will always lookup the class first, and thus expand the symbol table containing the class before it ever looks up a member function in that class. And because gdb looks in already expanded symbol tables before trying the index, any improper canonicalization that prevents symbols being found in the index won't ever matter. Another reason why such bugs can get missed is because of the bazillion different ways gdb tries to lookup a symbol if one way fails. Here again a lookup in the index can errantly fail, but because the symtab got expanded during the first attempt then when gdb tries to lookup the symbol in a different way (see, e.g., cp-namespace.c) subsequent lookups will get to use expanded symtabs. This matters because I'm looking into having gdb *only* use the index for lookups. Still don't know if this path will be fruitful, but iterating over already expanded symtabs when .gdb_index already knows exactly which symtabs to look at feels promising. [It also matters of course because it just makes gdb hard to hack on.] -- You are receiving this mail because: You are on the CC list for the bug.