Re: [RFC PATCH] Allow annotating calloc for Valgrind

[Alexander Monakov <amonakov@ispras.ru>]

On Sun, 2 Jul 2017, Rich Felker wrote:
> I'm not sure it makes sense to do -- is there a good reason dynamic
> linking can't be used when debugging memory errors? Surely some apps
> (especially proprietary ones) might be shipped as static binaries, but
> these will likely lack debugging symbols anyway.

Perhaps the project is hard to rebuild with shared libc.so, for reasons
like using linker functionality (e.g. --wrap, linker scripts) that does
not have direct equivalents outside of fully-static linking.

But in any case, even if there are doubts as to *why* people do it, we
know for certain that people hit this issue - there were two independent
reports on the mailing list this month. It would be nice to come up with
some kind of "canonical answer" for those situations - is it going to be
"just don't use static linking"?

> There are also fundamental limits to the correctness of any approach
> that uses static linking, since too much information has already been
> lost. It's calling the _name_ malloc, realloc, or free (not the code
> at the location; think aliases etc.) that must have the allocation
> semantics. Even if nothing weird is happening with aliases at the libc
> implementation level, the compiler could do major transformations with
> IPA (especially with LTO) that end up resulting in code being shared
> in unexpected ways.

Are you sure the same theory doesn't apply with shared libc.so? When you
call malloc internally in libc.so (e.g. printf->...->realloc), you're not
calling it via a dynamic relocation.

Alexander