Newer glibc have alternate ld.so _ld_runtime_resolve functions. Namely _dl_runtime_resolve_xsave and _dl_runtime_resolve_xsave'2 Those exist to save the full AVX registers, for applications that somewhat use an 'extended' x86_64 ABI. The problem is that applications need to run with LD_BIND_NOW set for kcachegrind to have some more meaningful usage. I believe callgrind/fn.c should be extended to handle these new ld.so symbols.
Created attachment 1666471 [details] valgrind-3.14.0-sfdc02538871.patch This patch "almost" works. The previous version did not work, so after some debugging, and using the --ct-verbose=N option, I noticed it never did check the codes. The problem was that it was "quick" checking if the object name started with /lib/ld or /lib64/ld. After also checking for /usr/lib/ld and /usr/lib64/ld the log shows: """ check_code: /usr/lib64/ld-2.17.so, pattern amd64-def, check 62 bytes of [48 83 ec...] found nothing. check_code: /usr/lib64/ld-2.17.so, pattern amd64-xsavec, check 11 bytes of [53 48 89...] found chunk 0 at 0x15dc0, checking 103 bytes of [48 89 4...] found chunk 0 at 0x15e90, checking 103 bytes of [48 89 4...] found chunk 1 at 0x15e90, checking 64 bytes of [49 89 c3...] found at offset 0x15e90. """ Unfortunately it did also annotate _dl_runtime_resolve_xsave; the check did find _dl_runtime_resolve_xsavec (note the ending 'c'). So, a patch unfortunately is unlikely to be trivial, as it is using more than one _dl_runtime_resolve* function. Any feedback or ideas? Note that the patch is exclusive to rhel7 and x86_64. A complete patch is far more complicated, but basically just need to search for _dl_runtime_resolve and 'interpolate' output of (gdb) x/186bx _dl_runtime_resolve_xsavec (gdb) disassemble _dl_runtime_resolve_xsavec adjusting the above as appropriate based on the function size and name, as well as adding the code ranges to not check.
Created attachment 1667472 [details] valgrind-3.14.0-rhbz1784541.patch The attached patch is an idea. It works for the user, now using a test package. Need to pass the argument --dl-runtime-resolve-pattern=PATTERN where PATTERN is either: amd64-def amd64-xsavec amd64-xsave amd64-fxsave and works on most environments using amd64-xsave, that could be made the default.
Apologies for the late response. I think I understand the issue and the solution you suggest. I think it should work. But it would be good to get some feedback from upstream about it. Do we have a simple testcase? If I understand the issue correctly then there could be multiple _dl_runtime_resolve* variants in ld.so and so you have to pick one and/or check in a particular order to select the right one. It would be nice if we could recognize them all if possible. Maybe by having a an array of runtime_resolve_addr/runtime_resolve_length to check against would do the trick.
I posted a patch based on Paulo's upstream: https://bugs.kde.org/show_bug.cgi?id=415293#c6
User did not yet reply my offer for a test package, and for what environment, e.g. plain valgrind or some toolset. In either case, the patch works for me, at least regarding the test case, and is unlikely to fail for some special test.
User confirmed the patch is fully functional. Patch applied cleanly on devtoolset-8.1 for rhel7. Where the user did want to test and/or use the test package.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (new packages: devtoolset-10-valgrind), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2020:5287