[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <878t9vlzh1.fsf@mid.deneb.enyo.de>
Date: Tue, 10 Apr 2018 19:53:46 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: tcmalloc compatibility
* Rich Felker:
> malloc interposition is undefined behavior (as is any interposition of
> standard functions), and is very difficult to actually support as an
> extension in a way that doesn't have lots of serious problems. This
> has been discussed before but I don't have links handy. I'll try to
> dig them up later. The glibc folks are also aware that it's broken (on
> glibc, it only works if you get lucky and follow unwritten rules)
We have some documentation nowadays:
<https://www.gnu.org/software/libc/manual/html_node/Replacing-malloc.html>
The remaining undocumented aspects concern cyclic dependencies, such
as the suitability of certain TLS models for implementing a custom
malloc, or using memory-allocating glibc functions such as fopen or
backtrace from the allocator itself.
In practice, malloc interposition works extremely well and causes few
issues due to interposition itself. Obviously, there are bugs, but
most of them would still be bugs if the allocator was non-interposing.
(Examples are lots of initial-exec TLS data, and incorrect alignment
for allocations.)
I believe musl uses less malloc internally, so it should be even more
compatible with an interposing malloc implementation than glibc.
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.
