Re: [PATCH 06/13] gdb: check exact results in the canonicalize selftest

[Simon Marchi <simark@simark.ca>]

On 10/21/26 1:48 PM, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi <simark@simark.ca> 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 <unsigned char N>
    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 <unsigned int N>
    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