libiberty: support digits in cpp mangled clone names

Currently libiberty fails to demangle the name of cloned functions if
the clone-type-identifier contains numbers.

This can be observed with the following example:

    $ cat > ex.cc <<EOT
    void foo (float *, float *)
      __attribute__((target_clones("avx2,avx,sse4.1,default")));

    void foo (float *, float *) {}
    EOT
    $ gcc -c ex.cc
    $ nm -C ex.o | grep foo
    0000000000000000 i foo(float*, float*)
    0000000000000026 t foo(float*, float*) [clone .avx.1]
    0000000000000013 t _Z3fooPfS_.avx2.0
    0000000000000000 t foo(float*, float*) [clone .default.3]
    0000000000000000 W foo(float*, float*) [clone .resolver]
    0000000000000039 t _Z3fooPfS_.sse4_1.2

In this example, gcc creates clones for the FOO function, each matching
one of the specified targets.  When inspecting the binary, nm (and other
libiberty-based tools, including gdb) fails to demangle the symbol names
if the clone identifier contains numbers.

Form my understanding of the mangling convention[1], clone names are
part of vendor-specific suffixes and do not have rule preventing them
from containing digits.

This commit proposes to fix the demangling.  With this commit (ported to
binutils), nm gives the following output:

    $ nm-new -C ex.o | grep foo
    0000000000000000 i foo(float*, float*)
    0000000000000026 t foo(float*, float*) [clone .avx.1]
    0000000000000013 t foo(float*, float*) [clone .avx2.0]
    0000000000000000 t foo(float*, float*) [clone .default.3]
    0000000000000000 W foo(float*, float*) [clone .resolver]
    0000000000000039 t foo(float*, float*) [clone .sse4_1.2]

Tested on x86_86-linux with 'make check-libiberty'.

[1] https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling

libiberty/ChangeLog:

	* cp-demangle.c (d_clone_suffix): Support digits in clone tag
	names.
	* testsuite/demangle-expected: Check demangling of clone symbols
	with digits in name.

0 files changed, 0 insertions, 0 deletions