[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAArOQ2WK0-WCgf9unNPnQv0ZVRtV1PgOm2wQwEW808nhBx3yOQ@mail.gmail.com>
Date: Tue, 10 Apr 2018 10:45:03 -0400
From: Bobby Powers <bobbypowers@...il.com>
To: musl@...ts.openwall.com
Subject: Re: tcmalloc compatibility
On Tue, Apr 10, 2018 at 2:34 PM Rich Felker <dalias@...c.org> wrote:
> This claim doesn't seem to be well-justified. Myself and members of
> our community have written a lot on why existing malloc interposition
> hacks are broken, but there's also an interest in what would take to
> make it work, and I particularly am interested in this from a
> standpoint that musl's malloc is not very good, and that being able to
> dynamically interpose it would facilitate developing and testing a
> replacement.
This sounds super interesting -- what needs to happen to make progress
on this? I would love to help out.
> Note however that if malloc interposition is supported at some point,
> there will be a specification for constraints on the malloc
> implementation including what functions you can call from it (e.g.
> something like AS-safety), and bug reports for implementations that do
> things outside this spec (and thereby inherently can't work safely or
> reliably) will not be considered bugs.
That sounds reasonable. Some existing software (like Hoard) goes out
of its way to interpose on all functions that might call into malloc
to ensure the system allocator isn't called indirectly:
https://github.com/emeryberger/Heap-Layers/blob/master/wrappers/wrapper.cpp
yours,
Bobby
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.
