[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.20.13.1707021854060.18055@monopod.intra.ispras.ru>
Date: Sun, 2 Jul 2017 19:16:15 +0300 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: musl@...ts.openwall.com
Subject: Re: [RFC PATCH] Allow annotating calloc for Valgrind
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
