• Bug#1108037: linux-perf: perf report --demangle only works on some(?) s

    From Ben Hutchings@21:1/5 to [email protected] on Wed Jul 9 18:20:01 2025
    XPost: linux.debian.kernel

    Control: tag -1 moreinfo

    On Thu, 19 Jun 2025 16:09:24 +0200 =?utf-8?B?0L3QsNCx?= <[email protected]> wrote:
    Package: linux-perf
    Version: 6.1.140-1
    Version: 6.12.30-1
    Version: 6.12.32-1
    Severity: normal

    Dear Maintainer,

    I'm attaching a tarball that, when extracted in the home directory,
    should demonstrate the issue.

    Running perf report -g --demangle shows
       Samples: 278K of event 'cycles:u', Event count (approx.): 183133005676 >     Children      Self  Command  Shared Object         Symbol
       +   98.44%     0.00%  bench    bench                 [.] main
       +   89.76%     0.00%  bench    bench                 [.] _ZN5Botan11Cipher_Mode6updateITkNS_8concepts21resizable_byte_bufferESt6vectorIhNS_16secure_allocatorIhEEEEEvRT_m
    [...]

    None of bfd_demangle() from libbfd, cplus_demangle() from libiberty, abi::__cxx_demangle() from libstdc++ are able to demangle this symbol.
    (We currently configure perf to use abi::__cxx_demangle.)

    The llvm-cxxfilt command demangles it to "void Botan::Cipher_Mode::update<std::vector<unsigned char, Botan::secure_allocator<unsigned char>>>(std::vector<unsigned char, Botan::secure_allocator<unsigned char>>&, unsigned long)" but it seems
    to be ignoring part of the symbol, specifically "Botan::concepts::resizable_byte_buffer".

    If I delete the "Tk" from the mangled symbol then they all agree it
    should be demangled to "void
    Botan::Cipher_Mode::update<std::vector<unsigned char, Botan::secure_allocator<unsigned char>>>(std::vector<unsigned char, Botan::secure_allocator<unsigned char>>&, unsigned long)".

    What does the actual declaration of this function look like, and what
    toolchain are you using to compile it?

    Ben.

    --
    Ben Hutchings
    73.46% of all statistics are made up.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmhulY4ACgkQ57/I7JWG EQllrg//f/ZRpbD8pKhAohup63F+P6S1WWdpot7vVp5SAjNfTdQOzwcQIA2U20I1 gfDrsUyaE0AnP/QDYiJ0VCdeSeG0s81tB96NcP+s7+hX1NxH+FECrxM828DItwhh 0WmGAbMwiyRRvD8LobQjdAN3wEh8OXmZ/PsRIheZW1VI5UBEhcqBzeKvy2yxLP/5 +kNlIWxwy8xODTiaT9ydPyGxnJf4b5OHpvGyGOza2Vk214Lqqf5eGz56aW+CKd7g 56f+aB2QlUtRdC0PVWyht6asMLJh9RvAYt0s/SfLhhZUSC+fBoRlzHo/8pXspbtG zINUQXQzDmhV6BM8TAtVYijPDaaviXDQezRjz1YWB5Hjahr139IPEhf5ovVxActX QIiTJPYJ1n8LHQvJmwLYKqHoZWnTVDN4epSw8gVNcfOzN5wHPN4zjDa8RJ7nGYz2 OwSBdxE4zIk5l13qOmEp1oKnBRjCwdz+61M7gd3TmfvHQ2JJ4sFW/P4umF42Peee 7zx8yOzSGbW2V2FEj/Pn+ZlbVSvh+hglTl+Jrx+q7iPbqwZMLsVFWh8dORv8zBsp /Bd0X+w6MoDB72s0xd3VMd4E6+gNQPL4ksE/gMBKXe7i2RPiTM1mNCxkVcWB3Llm XXiNQo4C68Yt5DMqYW2nGEU0+/n4c7MM1v9xqxi4WDg6zRHdCzU=
    =98dT
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?utf-8?B?0L3QsNCx?=@21:1/5 to Ben Hutchings on Wed Jul 9 19:20:01 2025
    XPost: linux.debian.kernel

    Control: tag -1 - moreinfo

    On Wed, Jul 09, 2025 at 06:15:10PM +0200, Ben Hutchings wrote:
    What does the actual declaration of this function look like, and what toolchain are you using to compile it?

    I get this out of src:botan3 3.7.1+dfsg-2 src/lib/modes/cbc/cbc.cpp
    when building with clang trunk (21.0.0 (++20250519112653+d0ee35851bb9-1~exp1~20250519112844.1459))
    (from http://apt.llvm.org/bookworm/)
    when configuring as ./configure.py --minimized-build --enable-modules cbc,twofish
    then building with make build/obj/lib/modes_cbc.o

    The construction looks like
    class secure_allocator { /* ... */ };
    using secure_vector = std::vector<T, secure_allocator<T>>;

    class BOTAN_PUBLIC_API(2, 0) Cipher_Mode : public SymmetricAlgorithm {
    template <concepts::resizable_byte_buffer T>
    void update(T& buffer, size_t offset = 0) {
    // ...
    }
    }

    class CBC_Mode : public Cipher_Mode {}
    class CBC_Encryption : public CBC_Mode {
    private:
    void finish_msg(secure_vector<uint8_t>& final_block, size_t offset = 0) override;
    }

    void CBC_Encryption::finish_msg(secure_vector<uint8_t>& buffer, size_t offset) {
    // ...

    update(buffer, offset);
    }
    (there's some other callers but they all use the same update overload).

    On Thu, 19 Jun 2025 16:09:24 +0200 =?utf-8?B?0L3QsNCx?= <[email protected]> wrote:
       +   89.76%     0.00%  bench    bench                 [.] _ZN5Botan11Cipher_Mode6updateITkNS_8concepts21resizable_byte_bufferESt6vectorIhNS_16secure_allocatorIhEEEEEvRT_m
    The llvm-cxxfilt command demangles it to "void Botan::Cipher_Mode::update<std::vector<unsigned char, Botan::secure_allocator<unsigned char>>>(std::vector<unsigned char, Botan::secure_allocator<unsigned char>>&, unsigned long)" but it seems
    to be ignoring part of the symbol, specifically "Botan::concepts::resizable_byte_buffer".

    So the full declaration will be something like
    template<concepts::resizable_byte_buffer = std::vector<unsigned char, Botan::secure_allocator<unsigned char>>> // except as an instantiation, not a default
    void Botan::Cipher_Mode::update(std::vector<unsigned char, Botan::secure_allocator<unsigned char>>, unsigned long);
    so llvm-cxxfilt gets it mostly right.

    I don't really see why the concept bit is in there either,
    it feels like it ought to be immaterial?

    If I delete the "Tk" from the mangled symbol then they all agree it
    should be demangled to "void
    Botan::Cipher_Mode::update<std::vector<unsigned char, Botan::secure_allocator<unsigned char>>>(std::vector<unsigned char, Botan::secure_allocator<unsigned char>>&, unsigned long)".

    This must mean that's "The koncept" as an extension, then, clearly?
    Maybe this wants to get forwarded to LLVM more-so than anything else.

    Building with bookworm GCC doesn't give give me any symbols
    matching /update/ except for an update_granularity.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEfWlHToQCjFzAxEFjvP0LAY0mWPEFAmhuo+8ACgkQvP0LAY0m WPGDbQ//Y9SZeoBnJmB2OzvATmxXv5jVsDRA2JivHn/BMUGhqdpI2cYdGze2gtVw 7+JiWDwteBYdu2YjUIXymVjiR9To49aZuVvx0tXGaT3XMWbMn2l/5yMlem5cAzlZ 8y61tVhnfwgatXTfWigWMmYEyTbXjH9/Qu8vvNv4gspFE3iukcRCt/sesOweBnCA zVIV3MkyYZ67AxR1YclHV64A/Kmn5PXZh9G9foaHDytaCM5Hp8rXaN8bZuURI6TK /AURoueWifFzI4hc34qHliczjv2I+071mi3Zu7hkj2qp6PzLvaP2H5S6G6hbwesL dI/XD1OLY/+Pa1sLxtC87Aiwqf9zQWipOio3u0CXNCr+PTuTiLBH448l8GtLkV2H KfEgaiGcQO72AhWzQ9NTl2/u/F8mNGoLe016ZbNNyescvn3Y3Uc5t6Dg7OdrBqhB bmYm3HHtxd6DiFvu8RcUjxosxeo/vl/7y0eMm7kPxN/psNrvz+mNz68rUq7XReAE dw8v4CW/siNZ5XsiPSJZ0OwJbLfPKAGVeG1twDpXMgosVYEBGZlYxoz0tiaVQfIZ 3uSMqhsa2Z0U1brdwCJ8yZV9nC+vlxqocRKW47UJiLKtk+3sGXKPIMC19/45attU HQ1xXCIB1peMNvqEseM2YP718o+zBjGR90U3dNZfx3rl0Y91g/0=
    =xcSB
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ben Hutchings@21:1/5 to All on Fri Jul 11 00:30:01 2025
    XPost: linux.debian.kernel

    On Wed, 2025-07-09 at 19:16 +0200, наб wrote:
    Control: tag -1 - moreinfo

    On Wed, Jul 09, 2025 at 06:15:10PM +0200, Ben Hutchings wrote:
    What does the actual declaration of this function look like, and what toolchain are you using to compile it?
    [...]
    So the full declaration will be something like
    template<concepts::resizable_byte_buffer = std::vector<unsigned char, Botan::secure_allocator<unsigned char>>> // except as an instantiation, not a default
    void Botan::Cipher_Mode::update(std::vector<unsigned char, Botan::secure_allocator<unsigned char>>, unsigned long);
    so llvm-cxxfilt gets it mostly right.

    I don't really see why the concept bit is in there either,
    it feels like it ought to be immaterial?

    If I delete the "Tk" from the mangled symbol then they all agree it
    should be demangled to "void Botan::Cipher_Mode::update<std::vector<unsigned char, Botan::secure_allocator<unsigned char>>>(std::vector<unsigned char, Botan::secure_allocator<unsigned char>>&, unsigned long)".

    This must mean that's "The koncept" as an extension, then, clearly?
    Maybe this wants to get forwarded to LLVM more-so than anything else.
    [...]

    You forwarded this to
    <https://github.com/llvm/llvm-project/issues/147790> and the response
    was that this extension was propsoed in <https://github.com/itanium-cxx-abi/cxx-abi/issues/24> (opened in
    2017!).

    - The "Tk" sequence seems to be first mentioned by zygoloid on Mar 31,
    2023

    - g++ started generating this in  <https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c3f281a0c1ca50e4df5049923aa2f5d1c3c39ff6>
    (September 2023)

    - libiberty imported that change in  <https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=e2a26339456487e80344a8c3bd0f10711ff28567>
    (January 2024)

    So it seems like the GNU tools also use this sequence, but perhaps they
    have diverged from LLVM on the precise syntax...

    Ben.

    --
    Ben Hutchings
    Never attribute to conspiracy what can adequately be explained
    by stupidity.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmhwIMgACgkQ57/I7JWG EQnCfw//fyqArqVtScvoB/fLRsg/NKor2OS3OAHUp/Toj4Jr7McG+2DZn+LOf9me 3yb9U82/iu4ZCLbsoiNHMg4jpJmeU3gvTMzt7SC9qZZzSyTHegl8jVFIC0ZqSKZ5 EkMqMghFrgfOOgNrXL0CgxGOdceSc98UbBFgcQ7aoLaitOoOv957Tc7jM/H9+SRs 0jWEZ7n4MxLF9Qe9/OfPmD2qzXYbuirqk4gBaCT2INTbklh4rLMaK++dBbejuHFt Ps1VU4PQ0stOiTnBXXKh/2bH3bjHs6iT5YsZgQadWHzciGA8ZViw7wQ1Bb7x2LHi M8WK4aljmzAORXa6/gdR8xkJFJSOFb6zvpgXQlaBIboQiKsnIp/ESbEQZJcxCJXt LM61Bo5XmFbAxFuZMQsbs9J/EuLFMQ5SEMvenTEUJmZvTvlF+it2sbKwXCqJAm04 Kn9XY/1kwFWgxx50nqsZ4KwpHAj2bhl0E0nNR8K10PzOCLjbMg9ptndyk4URfBg1 hrNPatzldjV3PszFWxcPRYKW6pfevOUyEqCvvjIaVp6+H+B1csBb8PGsU90z7jPN +o67NTb9GxUdaBj5hnZbLof8VWed2fZN8DRij7Xk1a6g+5UI4VbpBZxGA7yzhXsm FQLmKmx0i02doaNpnVQavE/eFql2457Wnkknb/OVFXFfzD7GEds=
    =o4f3
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)