https://bugs.kde.org/show_bug.cgi?id=286864
Paul Floyd <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #12 from Paul Floyd <[email protected]> --- (In reply to Matt from comment #9) > It does expose an issue on Ubuntu/Debian 64 bit machines and maybe others. > Is it reasonable to have no entry point for strlen(), which is an ANSI C > library function? > It would certainly be 'easier' in some sense if valgrind moved to another > means of detecting a library with proper debug symbols. I don't think that you understand the problem. Valgrind (and in particular, memcheck) is running and checking the guest binary from the get go. That means that everything runs under Valgrind, including the code for ld.so that loads any shared libraries like libc.so. Because libc.so isn't even loaded yet when ld.so is doing its stuff ld.so also provides its own implementation of a few libc functions like malloc and strlen. Some platforms have optimised versions of strlen that generate many false positives. We need to redirect strlen to avoid them and so strlen redirection is mandatory. The only other thing that I could do is to make this a configure time check. That way packagers could turn off the requirement. Obviously if the distro ignores our instructions in README_PACKAGERS and ld.so strlen needs to be redirected and Valgrind allows it to be not redirected then you will have an unusable Valgrind. -- You are receiving this mail because: You are watching all bug changes.
