Bug 1784541

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