From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24128 invoked by alias); 26 Jun 2015 13:21:00 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 24113 invoked by uid 89); 26 Jun 2015 13:21:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vn0-f74.google.com Received: from mail-vn0-f74.google.com (HELO mail-vn0-f74.google.com) (209.85.216.74) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 26 Jun 2015 13:20:58 +0000 Received: by vnav203 with SMTP id v203so3461517vna.0 for ; Fri, 26 Jun 2015 06:20:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:message-id:date:subject:from:to:cc :content-type; bh=i0VnEIXEIWq1vUmu2m4CPzVvBbK5Kb2ahxdsWqfATc8=; b=XPa/2TxamBqrKd4zpi4xcoWNyJuzkzzX/Ov+tZJpR8OWohW8OEFhi23eLilyzXVshB t5cTokxlUKS3CLVniqI8rQ/2+kN5jEROdSAOAgtY56wKK8MK+aXAbbDRlDId7E97DGtF KLZOvUthmd8DYXEOVJXtSayM8cgtFQv9tVv76sjBorCE6+wltL+y4v7TMZN2U4aDU8Oi rs1r0G38hsagxs468QD1jdG+EZjSErzZkd/y3O+zqZHUlHjEa4cKgCDOkX154MjObcfz ea3hgLbZ/YectNY9tugYhanUCRt8fAn+ftrdKCw8OBVV9p4S+8x4rrlMVlcGhs7gMqTT 1cjw== X-Gm-Message-State: ALoCoQmm7bxciaN6sSnV2fhXBFqnv2nTVJMZp+7GXUtChPFIm8x5snHVg0L5bxsUy4BwzmvQDiEU MIME-Version: 1.0 X-Received: by 10.129.97.7 with SMTP id v7mr1615199ywb.45.1435324856267; Fri, 26 Jun 2015 06:20:56 -0700 (PDT) Message-ID: <001a114934d832407405196b9ce6@google.com> Date: Fri, 26 Jun 2015 13:21:00 -0000 Subject: Re: [PATCH] PR 16253 revisited From: Doug Evans To: Keith Seitz Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00566.txt.bz2 Keith Seitz writes: > This is a request for formal review of an earlier proposed workaround > for c++/16253. A complete description of the proposal is below. > > Changes since proposal (with Doug's assistance -- THANKS DOUG!): > - Add exact/best domain matching concept to block_lookup_symbol. > - Add comment to block_lookup_symbol explaining why c++/16253 is not > likely to affect blocks defined in functions. > - Update tests to coverage test block_lookup_symbol. > > --- > > Last year a patch was submitted/approved/commited to eliminate > symbol_matches_domain which was causing this problem. It was later reverted > because it introduced a (severe) performance regression. > > Recap: > > (gdb) list > 1 enum e {A,B,C} e; > 2 int main (void) { return 0; } > 3 > (gdb) p e > Attempt to use a type name as an expression > > The parser attempts to find a symbol named "e" of VAR_DOMAIN. > This gets passed down through lookup_symbol and (eventually) into > block_lookup_symbol_primary, which iterates over the block's dictionary > of symbols: > > for (sym = dict_iter_name_first (block->dict, name, &dict_iter); > sym != NULL; > sym = dict_iter_name_next (name, &dict_iter)) > { > if (symbol_matches_domain (SYMBOL_LANGUAGE (sym), > SYMBOL_DOMAIN (sym), domain)) > return sym; > } > > The problem here is that we have a symbol named "e" in both STRUCT_DOMAIN > and VAR_DOMAIN, and for languages like C++, Java, and Ada, where a tag name > may be used as an implicit typedef of the type, symbol_matches_domain ignores > the difference between VAR_DOMAIN and STRUCT_DOMAIN. As it happens, the > STRUCT_DOMAIN symbol is found first, considered a match, and that symbol is > returned to the parser, eliciting the (now dreaded) error message. > > Since this bug exists specifically because we have both STRUCT and VAR_DOMAIN > symbols in a given block/CU, this patch rather simply/naively changes > block_lookup_symbol_primary so that it continues to search for an exact > domain match on the symbol if symbol_matches_domain returns a symbol > which does not exactly match the requested domain. > > This "fixes" the immediate problem, but admittedly might uncover other, > related bugs. [Paranoia?] However, it causes no regressions (functional > or performance) in the test suite. A similar change has been made > to block_lookup_symbol for other cases in which this bug might appear. > > The tests from the previous submission have been resurrected and updated. > However since we can still be given a matching symbol with a different domain > than requested, we cannot say that a symbol "was not found." The error > messages today will still be the (dreaded) "Attempt to use a type name..." > > ChangeLog > > PR 16253 > * block.c (block_lookup_symbol): For non-function blocks, > continue to search for a symbol with an exact domain match > Otherwise, return any previously found "best domain" symbol. > (block_lookup_symbol_primary): Likewise. > > testsuite/ChangeLog > > PR 16253 > * gdb.cp/var-tag-2.cc: New file. > * gdb.cp/var-tag-3.cc: New file. > * gdb.cp/var-tag-4.cc: New file. > * gdb.cp/var-tag.cc: New file. > * gdb.cp/var-tag.exp: New file. LGTM. > + # These tests exercise lookup of symbols using the "quick fns" API. > + # Each of them is in a separate CU as once its CU is expanded, > + # we're no longer using the quick fns API. > + gdb_test "print E2" "= a2" > + gdb_test "ptype E2" "type = enum E2 {.*}" > + gdb_test "print S2" "= {}" > + gdb_test "ptype S2" "type = struct S2 {.*}" > + gdb_test "print U2" "= {.*}" > + gdb_test "ptype U2" "type = union U2 {.*}" > + } Just a note for the archives: The ptypes here will work with expanded symtabs since they follow the print. If we really want full coverage we'd have to create tests where the VAR_DOMAIN variable appears ahead of the STRUCT_DOMAIN type (or even VAR_DOMAIN type for c++), and try all four combinations (var/type first -x- looking for var/type). That'd require some handcrafted dwarf that had both cases (var first or type first), and felt excessive for this particular case.