[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170702163111.GL1627@brightrain.aerifal.cx>
Date: Sun, 2 Jul 2017 12:31:11 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [RFC PATCH] Allow annotating calloc for Valgrind
On Sun, Jul 02, 2017 at 07:16:15PM +0300, Alexander Monakov wrote:
> 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"?
I think "debugging tool X has inherent limitations with static
linking, so you should dynamic-link to use it" is a fairly reasonable
position to take. Switching to dynamic-linking everything may be
complex or difficult for some larger projects, but just dynamically
linking libc.so and static linking everything else should not be hard.
> > 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.
Well printf doesn't call realloc, but some things will, and yes I
think you're right. This problem might go away if we made an effort to
actually support malloc interposition (with a well-defined model for
what you can and can't do rather than just being sloppy about it)
since libc-internal callers would have to go through the same
interfaces, but there's been some question whether, if we did this,
purely libc-internal (i.e. not "as if by malloc") allocations would be
subject to interposition or would always use an internal malloc. Maybe
it doesn't matter one way or the other if we assume there are not bugs
in the purely libc-internal use of the allocator.
Rich
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.
