When dlopen is used we might end up in an assembly powerpc/strcmp.S variant that is optimized in a way memcheck cannot proof correct: ==145240== Conditional jump or move depends on uninitialised value(s) ==145240== at 0x4042590: strcmp (strcmp.S:76) ==145240== by 0x401BC37: _dl_name_match_p (dl-misc.c:69) ==145240== by 0x401CA37: dl_open_worker_begin (dl-open.c:553) ==145240== by 0x4002593: _dl_catch_exception (dl-catch.c:237) ==145240== by 0x401C5E3: dl_open_worker (dl-open.c:782) ==145240== by 0x4002593: _dl_catch_exception (dl-catch.c:237) ==145240== by 0x401DFDB: _dl_open (dl-open.c:903) ==145240== by 0x443D58F: dlopen_doit (dlopen.c:56) ==145240== by 0x4002593: _dl_catch_exception (dl-catch.c:237) ==145240== by 0x400276B: _dl_catch_error (dl-catch.c:256) ==145240== by 0x443CDF3: _dlerror_run (dlerror.c:138) ==145240== by 0x443D673: dlopen_implementation (dlopen.c:71) ==145240== by 0x443D673: dlopen@@GLIBC_2.34 (dlopen.c:81) We try to intercept strcmp in ld.so, but might fail when strcmp is called before our interception code is loaded. Having an hardwire for ld.so strcmp (earlier intercept) would solve this.
Created attachment 183979 [details] Proposed hardwire
Tested on Fedora 43/Rawhide ppc64le setup. Pushed as: commit 78fe3625f6b8ed4de28527d71c4a98d70e5b3035 Author: Mark Wielaard <mark@klomp.org> Date: Mon Aug 18 15:30:47 2025 +0200 Add ppc64le linux hardwire for ld64.so.2 strcmp When dlopen is used we might end up in an assembly powerpc/strcmp.S variant that is optimized in a way memcheck cannot proof correct. We try to intercept strcmp in ld.so, but might fail when strcmp is called before our interception code is loaded. Having an hardwire for ld.so strcmp (earlier intercept) would solve this. https://bugs.kde.org/show_bug.cgi?id=508145