From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id PCtjO9U52mpN5gsAWB0awg (envelope-from ) for ; Thu, 22 Oct 2026 12:29:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1792686549; bh=yxENzYCzw033Uwsr/t3uWYJt2TwC9Sv5Hz4DqXCQzsE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=w/ByVE0g7w2BAs/tE/8OybWeWtN7rgjUf7LKU1Wt0lerjglnuECZdU1sfZNyYid2v O3K3WQS43IDpalfvEsXZpLQoxX+kiXNmIjiAEY8HzYp4Wmjw7UXP8nr4JF+unklHsi 3K92QIq1VAy2O1ZCEt0QfmQcuzr6lw3SJx/kvJmA= Received: by simark.ca (Postfix, from userid 112) id 68F12378002; Thu, 22 Oct 2026 12:29:09 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=Fp3gXkx2; dkim-atps=neutral Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id CDA991E007 for ; Thu, 22 Oct 2026 12:29:07 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2D45A4BA23D5 for ; Thu, 22 Oct 2026 16:29:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2D45A4BA23D5 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=Fp3gXkx2 Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 468B04BA2E3F for ; Thu, 22 Oct 2026 16:28:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 468B04BA2E3F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 468B04BA2E3F Authentication-Results: sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1792686520; cv=none; b=QlD2PG8w9LQnEm3lPbeogKtKY/y+axQCu1XaxXLIgsbIUMOY4fi+J3Or4teENXimYAR9t6r6GuFHdQMKYFyH/sOf+3Ro9SpNbAwJ4MnGZN0jgD/Yp4zu70Lht86olcda2bWBpMCTJASVfEr7j0xXKV5UMPQk3PfUdspJ7JeZ0z8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1792686520; c=relaxed/simple; bh=yxENzYCzw033Uwsr/t3uWYJt2TwC9Sv5Hz4DqXCQzsE=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=fBIwsUo6ORpkHk25C0dnMaW4I3UZmhq3Uu2+dOdlaHAvwds1LgjEfO9HN9ReV77PgV1RXCr7+R2Q5jvYp5G8YE/19m3iHQIhZ1GE7ym5DSFyxF+n8UPFlxPoFXJkOEjYeGyI/JwKrZtby+AE6S4hKvoobccez75LBiSCb4Uais4= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=Fp3gXkx2 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 468B04BA2E3F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1792686518; bh=yxENzYCzw033Uwsr/t3uWYJt2TwC9Sv5Hz4DqXCQzsE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Fp3gXkx211d9dFagbd/ST9a/rUF4njF0pV794YFO6SdunSAqUayB92uv6M7y9KVM6 gwHadDfTPdx8tNwfDkpIdpT4hkZwagm35jHdVk3uphdynwfH4gHOAAyFooOw0XEp2C vZ5lM6GjP6h6o37LQD7x13UwKWcnX9pQeiYDaN0E= Received: by simark.ca (Postfix) id E5AA51E007; Thu, 22 Oct 2026 12:28:37 -0400 (EDT) Message-ID: Date: Thu, 22 Oct 2026 12:28:36 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 06/13] gdb: check exact results in the canonicalize selftest To: Tom Tromey Cc: Simon Marchi , gdb-patches@sourceware.org References: <20261020162054.2140671-1-simon.marchi@efficios.com> <20261020162054.2140671-7-simon.marchi@efficios.com> <87wlrbyt86.fsf@tromey.com> <874iefyou5.fsf@tromey.com> <901d45a4-7942-4258-ae4a-9daa2b5e5a6e@simark.ca> <87qzhjx7uq.fsf@tromey.com> Content-Language: fr From: Simon Marchi In-Reply-To: <87qzhjx7uq.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 10/21/26 1:48 PM, Tom Tromey wrote: >>>>>> "Simon" == Simon Marchi writes: > >>> Yeah, I think it would be better if they didn't. >>> >>> Though maybe we're already in trouble here due to the builtin type stuff >>> doing: > >>> ... where "short unsigned" is a valid spelling as well. > > Simon> What do you mean by that? > > What I mean is that my wish is that gdb internals shouldn't care about > the precise spelling that the canonicalizer spits out. > > However, builtin types are given hard-coded names in the source. > > Now, I was under the impression that some spot looked through the > builtin types by name. But I can't actually find that, so maybe it > doesn't happen. > > But if it does happen, then the builtin type code is working against the > approach I had been wanting. Let me share the broader context of what I am trying to fix, perhaps that will make more sense, or perhaps you can help me think where to go with all this. We have a few bugs open about symbol lookup problems when non-type template parameters (I don't know why it's not called "value template parameters") are involved, I'm trying to fix some of them. For example, if you have this: template struct C {}; C<0> c; And you compile it with clang, you get a type with DW_AT_name: C<(unsigned char)'\x00'> Following this series (which adds support for recognizing hex escapes), it canonicalizes to: C<(unsigned char)0> If the user does: (gdb) ptype C<0> GDB does does not find the type. They would have to do: (gdb) ptype C<(unsigned char)0> Since `C<0>` is how they wrote the type in the source (and it's a very reasonable way to spell it), my goal is to make it work. Making it work, as far as I understand, involves teaching strncmp_iw_with_mode to be a bit smarter when comparing template arguments, to understand that "0" and "(unsigned char)0" match. It's not going to be a literal string comparison anymore. Similarly, for gcc, it might be necessary to teach it that "2" and "2u" match (if you recall gcc bug 81932). To implement this, strncmp_iw_with_mode will need to have some form of integer literal parsing, but it will be limited to just what can possibly be found in a canonical name. For example, it can assume that all the literals it will see are in decimal form. It won't see a '\x00' or a 0x0. It can also assume that integer suffix have been normalized, for instance 2U is changed to 2u. I also have a patch (not sent) that normalizes the integer representation, so that if the user typed: (gdb) ptype C<(unsigned int) -1> It gets normalized to C<4294967295u> which is what clang actually emits for: template struct C {}; C<(unsigned int)-1> c; With this, strncmp_iw_with_mode will be able to assume that integers have been converted to their "normal" form, which subsequently makes comparison much easier. In any case, changing how the tests work is not mandatory to making this work, I just happen to like if the test demonstrates precisely what the function does. Simon