[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 10 Nov 2020 19:52:17 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH v2] MT fork
On Mon, Nov 09, 2020 at 05:23:21PM -0500, Rich Felker wrote:
> On Mon, Nov 09, 2020 at 10:59:01PM +0100, Szabolcs Nagy wrote:
> > (not ideal, since then interposers can't see all
> > allocations, which some tools would like to see,
> > but at least correct and robust. and it is annoying
> > that we have to do all this extra work just because
> > of mt-fork)
>
> Yes. On the other hand if this were done more rigorously it would fix
> the valgrind breakage of malloc during ldso startup..
>
> > > The other pros of such an approach are stuff like making it so
> > > application code doesn't get called as a callback from messy contexts
> > > inside libc, e.g. with dynamic linker in inconsistent state. The major
> > > con I see is that it precludes omitting the libc malloc entirely when
> > > static linking, assuming you link any part of libc that uses malloc
> > > internally. However, almost all such places only call malloc, not
> > > free, so you'd just get the trivial bump allocator gratuitously
> > > linked, rather than full mallocng or oldmalloc, except for dlerror
> > > which shouldn't come up in static linked programs anyway.
> >
> > i see.
> > that sounds fine to me.
>
> I'm still not sure it's fine, so I appreciate your input and anyone
> else's who has spent some time thinking about this.
Here's a proposed first patch in series, getting rid of getdelim/stdio
usage in ldso. I think that suffices to set the stage for adding
__libc_malloc, __libc_free, __libc_calloc, __libc_realloc and having
ldso use them.
To make this work, I think malloc needs to actually be a separate
function wrapping __libc_malloc -- this is because __simple_malloc
precludes the malloc symbol itself being weak. That's a very slight
runtime cost, but has the benefit of eliminating the awful hack of
relyin on link order to get __simple_malloc (bump allocator) to be
chosen over full malloc. Now, the source file containing the bump
allocator can define malloc as a call to __libc_malloc, and provide
the bump allocator as the weak definition of __libc_malloc.
mallocng/malloc.c would then provide the strong definition of
__libc_malloc.
For the other functions, I think __libc_* can theoretically just be
aliases for the public symbols, but this may (almost surely does)
break valgrind, and it's messy to do at the source level, so perhaps
they should be wrapped too. This should entirely prevent valgrind from
interposing the libc-internal calls, thereby fixing the longstanding
bug where it crashes by interposing them too early.
Rich
View attachment "0001-drop-use-of-getdelim-stdio-in-dynamic-linker.patch" of type "text/plain" (3125 bytes)
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.
