On openSUSE tumbleweed, I run into: ... FAIL: gdb.cp/typeid.exp: before starting: print &typeid(i) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(i) == &typeid(typeof(i)) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(cp) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(cp) == &typeid(typeof(cp)) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(ccp) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(ccp) == &typeid(typeof(ccp)) ... The first in more detail: ... (gdb) file typeid^M Reading symbols from typeid...^M (gdb) print &typeid(i)^M could not find typeinfo symbol for 'int'^M (gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(i) ... Easily reproduced on command line using: ... $ gdb -batch ./outputs/gdb.cp/typeid/typeid -ex "print typeid (int)" could not find typeinfo symbol for 'int' ... Interestingly though, if we first start, we get:: ... $ gdb -batch ./outputs/gdb.cp/typeid/typeid -ex start -ex "print typeid (int)" Temporary breakpoint 1 at 0x40112a: file typeid.cc, line 52. Temporary breakpoint 1, main () at typeid.cc:52 52 const std::type_info &xi = typeid(i); $1 = {_vptr.type_info = 0x7ffff7fa0218 <vtable for __cxxabiv1::__fundamental_type_info+16>, __name = 0x7ffff7f31554 <typeinfo name for int> "i"} ... In the latter case we get the minimal symbol from: ... $ readelf -r /usr/lib64/libstdc++.so.6.0.29 | c++filt | grep "typeinfo for int" 00000020a710 04d300000001 R_X86_64_64 000000000020a738 typeinfo for int@@CXXABI_1.3 + 0 00000020a730 04d300000001 R_X86_64_64 000000000020a738 typeinfo for int@@CXXABI_1.3 + 0 ... While in the former case we fail to find the minimal symbol: ... $ readelf -r ./outputs/gdb.cp/typeid/typeid | c++filt | grep "typeinfo for int" 000000403c20 000a00000005 R_X86_64_COPY 0000000000403c20 typeinfo for int@CXXABI_1.3 + 0 ... The only difference I notice is '@@' vs '@'.
Bisects to: ... commit 3f2e9699234ca31d083bc93ea6e03903f10baeaf Author: H.J. Lu <hjl.tools@gmail.com> Date: Sat Aug 22 08:31:53 2020 -0700 elf: Keep only one '@' for undefined versioned symbols The symbol string table in the .symtab section is optional and cosmetic. Keep only one '@' for undefined versioned symbols, which are defined in shared objects, in the symbol string table. Update "nm -D" to display only one '@' for undefined versioned symbols. ... Commit first appeared in 2.36 release.
I'm seeing this also on fedora asahi 39, aarch64-linux, with target board unix/-fPIE/-pie.