Message ID | yjt2mw7ewq2w.fsf@ruffy.mtv.corp.google.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 24720 invoked by alias); 26 Nov 2014 04:20:12 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 24704 invoked by uid 89); 26 Nov 2014 04:20:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-oi0-f74.google.com Received: from mail-oi0-f74.google.com (HELO mail-oi0-f74.google.com) (209.85.218.74) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 26 Nov 2014 04:20:10 +0000 Received: by mail-oi0-f74.google.com with SMTP id e131so246989oig.1 for <gdb-patches@sourceware.org>; Tue, 25 Nov 2014 20:20:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-type; bh=96w5VKNrj/vDfsmufZE+OAJODJyRVSf7powooF9WzgM=; b=VWbWEMbM5AtCVKrjJHBzeT3OnOyWJnW8Vw0KVHSepsm/4DHVngV9SRBNjD6xd1DPKr QMbgK/D7n3uySqvOeYmdemfyLZ7JpIehhTWZBKmzL9Z7kjg8BZ3DTh63jcdhfwgOrZbO jB4p3RiqGZByOyYHPF0+meeeyGnhhToNKFnqAUAFiCUQUkrBHFgKbDEADmSglfwqeFCA BcquhvDXy4Cb0QcXtSOIEzh3jBMzraxnPqQEeOighG5F6E0RvF2q0Q4slF+iak+sYmF0 FT3yeTlsvzycLvveGoLa1Ocq9w783eW5JcfGST9S2pXWMyBfO3FHo3kVw2AUC6ElIdCi U87Q== X-Gm-Message-State: ALoCoQmEO+Lj8OmXcLkrF4+HHpY79QCc9ABPIgXeB6TuhFG9n6vRPfD+1BCnKSTFwkr3bpFCqXsU4o3iYgKRP2FNeQEDmOBQbgLcHZDHNDe2ruAIFp3FXM4AyIEt7UcLJ/J2MIhcezNY15+U9wn7T87+0u4VLNhF6d/TdpsNfo10UsfUzq3oYIk= X-Received: by 10.42.194.204 with SMTP id dz12mr40469295icb.16.1416975608300; Tue, 25 Nov 2014 20:20:08 -0800 (PST) Received: from corpmail-nozzle1-2.hot.corp.google.com ([100.108.1.103]) by gmr-mx.google.com with ESMTPS id e24si129550yhe.3.2014.11.25.20.20.08 for <gdb-patches@sourceware.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Nov 2014 20:20:08 -0800 (PST) Received: from ruffy.mtv.corp.google.com ([172.17.128.44]) by corpmail-nozzle1-2.hot.corp.google.com with ESMTPS id PbXlynkv.1; Tue, 25 Nov 2014 20:20:08 -0800 From: Doug Evans <dje@google.com> To: gdb-patches@sourceware.org Subject: [PATCH 2/2] [PR symtab/17602] Fix arguments to symbol_name_cmp Date: Tue, 25 Nov 2014 20:20:07 -0800 Message-ID: <yjt2mw7ewq2w.fsf@ruffy.mtv.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes |
Commit Message
Doug Evans
Nov. 26, 2014, 4:20 a.m. UTC
Hi. This patch fixes pr 17602, the arguments to symbol_name_cmp are reversed, as explained in the comment in this patch. Regression tested on amd64-linux. 2014-11-25 Doug Evans <dje@google.com> PR symtab/17602 * linespec.c (iterate_name_matcher): Fix arguments to symbol_name_cmp.
Comments
Doug Evans <dje@google.com> writes: > - if (data->symbol_name_cmp (name, data->lookup_name) == 0) > + /* The order of arguments we pass to symbol_name_cmp is important as > + strcmp_iw, a typical value for symbol_name_cmp, only performs special > + processing of '(' to remove overload info on the first argument and not > + the second. The first argument is what the user provided, the second > + argument is what came from partial syms / .gdb_index. */ > + if (data->symbol_name_cmp (data->lookup_name, name) == 0) > return 1; /* Expand this symbol's symbol table. */ > return 0; /* Skip this symbol. */ Such odd feature is documented in the comments to strcmp_iw: As an extra hack, string1=="FOO(ARGS)" matches string2=="FOO". This "feature" is useful when searching for matching C++ function names (such as if the user types 'break FOO', where FOO is a mangled C++ function). A question not related to this patch too much, do you consider to move such c++ specific hack into c++ specific routine la_get_symbol_name_cmp?
On Wed, Nov 26 2014, Doug Evans wrote: > diff --git a/gdb/linespec.c b/gdb/linespec.c > index 5325702..35b0205 100644 > --- a/gdb/linespec.c > +++ b/gdb/linespec.c > @@ -982,7 +982,12 @@ iterate_name_matcher (const char *name, void *d) > { > const struct symbol_matcher_data *data = d; > > - if (data->symbol_name_cmp (name, data->lookup_name) == 0) > + /* The order of arguments we pass to symbol_name_cmp is important as > + strcmp_iw, a typical value for symbol_name_cmp, only performs special > + processing of '(' to remove overload info on the first argument and not > + the second. The first argument is what the user provided, the second > + argument is what came from partial syms / .gdb_index. */ > + if (data->symbol_name_cmp (data->lookup_name, name) == 0) > return 1; /* Expand this symbol's symbol table. */ > return 0; /* Skip this symbol. */ > } This seems to cause a regression for the Ada testcase "operator_bp.exp": > [...] > FAIL: gdb.ada/operator_bp.exp: break "+" (got interactive prompt) > FAIL: gdb.ada/operator_bp.exp: break "-" (got interactive prompt) > FAIL: gdb.ada/operator_bp.exp: break "*" (got interactive prompt) > FAIL: gdb.ada/operator_bp.exp: break "/" (got interactive prompt) > FAIL: gdb.ada/operator_bp.exp: break "mod" (got interactive prompt) > FAIL: gdb.ada/operator_bp.exp: break "rem" (got interactive prompt) > FAIL: gdb.ada/operator_bp.exp: break "**" (got interactive prompt) > [...] See https://sourceware.org/ml/gdb-testers/2014-q4/msg00126.html The problem occurs like this: (gdb) break "+" Function ""+"" not defined. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) FAIL: gdb.ada/operator_bp.exp: break "+" (got interactive prompt) When reverting the patch, the test succeeds again.
On Thu, Dec 4, 2014 at 3:48 AM, Andreas Arnez <arnez@linux.vnet.ibm.com> wrote: > On Wed, Nov 26 2014, Doug Evans wrote: > >> diff --git a/gdb/linespec.c b/gdb/linespec.c >> index 5325702..35b0205 100644 >> --- a/gdb/linespec.c >> +++ b/gdb/linespec.c >> @@ -982,7 +982,12 @@ iterate_name_matcher (const char *name, void *d) >> { >> const struct symbol_matcher_data *data = d; >> >> - if (data->symbol_name_cmp (name, data->lookup_name) == 0) >> + /* The order of arguments we pass to symbol_name_cmp is important as >> + strcmp_iw, a typical value for symbol_name_cmp, only performs special >> + processing of '(' to remove overload info on the first argument and not >> + the second. The first argument is what the user provided, the second >> + argument is what came from partial syms / .gdb_index. */ >> + if (data->symbol_name_cmp (data->lookup_name, name) == 0) >> return 1; /* Expand this symbol's symbol table. */ >> return 0; /* Skip this symbol. */ >> } > > This seems to cause a regression for the Ada testcase "operator_bp.exp": > >> [...] >> FAIL: gdb.ada/operator_bp.exp: break "+" (got interactive prompt) >> FAIL: gdb.ada/operator_bp.exp: break "-" (got interactive prompt) >> FAIL: gdb.ada/operator_bp.exp: break "*" (got interactive prompt) >> FAIL: gdb.ada/operator_bp.exp: break "/" (got interactive prompt) >> FAIL: gdb.ada/operator_bp.exp: break "mod" (got interactive prompt) >> FAIL: gdb.ada/operator_bp.exp: break "rem" (got interactive prompt) >> FAIL: gdb.ada/operator_bp.exp: break "**" (got interactive prompt) >> [...] > > See https://sourceware.org/ml/gdb-testers/2014-q4/msg00126.html > > The problem occurs like this: > > (gdb) break "+" > Function ""+"" not defined. > Make breakpoint pending on future shared library load? (y or [n]) n > (gdb) FAIL: gdb.ada/operator_bp.exp: break "+" (got interactive prompt) > > When reverting the patch, the test succeeds again. Yeah, found that last night. The problem is ada-lang.c:wild_match takes arguments in the opposite order of strcmp_iw. Working on a patch.
On Wed, Nov 26, 2014 at 1:00 AM, Yao Qi <yao@codesourcery.com> wrote: > A question not related to this patch too much, do you consider to move > such c++ specific hack into c++ specific routine la_get_symbol_name_cmp? I hadn't planned on it, at least not soon.
diff --git a/gdb/linespec.c b/gdb/linespec.c index 5325702..35b0205 100644 --- a/gdb/linespec.c +++ b/gdb/linespec.c @@ -982,7 +982,12 @@ iterate_name_matcher (const char *name, void *d) { const struct symbol_matcher_data *data = d; - if (data->symbol_name_cmp (name, data->lookup_name) == 0) + /* The order of arguments we pass to symbol_name_cmp is important as + strcmp_iw, a typical value for symbol_name_cmp, only performs special + processing of '(' to remove overload info on the first argument and not + the second. The first argument is what the user provided, the second + argument is what came from partial syms / .gdb_index. */ + if (data->symbol_name_cmp (data->lookup_name, name) == 0) return 1; /* Expand this symbol's symbol table. */ return 0; /* Skip this symbol. */ }