This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH v2] malloc: Remove malloc hooks (Bug 23328)
- From: Carlos O'Donell <carlos at redhat dot com>
- To: DJ Delorie <dj at redhat dot com>, Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Fri, 20 Jul 2018 21:38:30 -0400
- Subject: Re: [PATCH v2] malloc: Remove malloc hooks (Bug 23328)
- References: <email@example.com>
On 06/29/2018 10:57 PM, Carlos O'Donell wrote:
> - I worked with DJ to remove/finalize __morecore, __after_morecore_hook,
> and __default_morecore, along with fixing a bug with the mcheck support
> (an application requesting mcheck via MALLOC_CHECK_=3 or tunables or
> mallopt that *didn't* preload libmalloc-extras.so could abort with
> memory corruption).
> - Turned all the hooks into compat symbols so no new ABI will have them,
> but used GLIBC_PRIVATE symbols to keep libmalloc-extras.so working.
> - Fixed up the manual.
> - Added a NEWS entry.
Your review included a few suggestions:
- Cleanup the HOOK macro in malloc-extras.c, which could be done now
or later as a cleanup of the legacy implementation (Discussed by
you and DJ).
- I clarified to you my point about some APIs like mallopt remain,
but some options do nothing now (we can't entirely remove mallopt).
- A quick cleanup of $(objpfx) -> $(objpfx-common).
Did you have any further review?
Does this design of this patch implement what you thought would be
an appropriate solution to deprecating the hooks? Part of this design
is based on your feedback that you wanted to see some kind of shared
library that provided the features that the hooks used to provide,
and that's what we do here as we finalize (make compat symbolis) the
hooks and other APIs.
I would like to consider this for 2.28, because I want to see these
symbols removed. Every release that goes by with them is another
machine ABI that includes them (RISC-V, and next C-SKY).
I'm open to derision and shouts of "No, put it in 2.29." :-)