From: Florian Weimer <fweimer@redhat.com>
To: Joseph Myers <joseph@codesourcery.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH] malloc: Deprecate hook variables, __default_morecore, <mcheck.h>
Date: Tue, 15 Nov 2016 13:22:00 -0000 [thread overview]
Message-ID: <11f59117-e5a4-4c62-739c-e05e01ee43b3@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1610261548400.23075@digraph.polyomino.org.uk>
On 10/26/2016 05:55 PM, Joseph Myers wrote:
> On Wed, 26 Oct 2016, Florian Weimer wrote:
>
>> The functionality in <mcheck.h> will eventually be replaced with
>> no-op functions (and a separate, preloadable DSO).
>
> If you declare functionality deprecated then you need to update the manual
> accordingly. But I don't think the right approach is to declare
> deprecated on an "eventually be replaced" basis. Rather, the deprecation
> and the new DSO should be in the same patch series, going in the same
> glibc version, so the NEWS file and the main documentation can tell users
> of the mtrace script to preload the DSO and remove calls to the mtrace
> function (if that's the intended way to update code using mtrace and the
> one to be used for all the glibc tests that make use of it).
In my opinion, the larger ecosystem already provides suitable replacements.
* <mcheck.h> and all malloc hook functions are now deprecated. Future
implementations of the mcheck- and mtrace-related functions will not
have any effect, and glibc will stop calling the hook functions from
its malloc implementation. Instead of mcheck and mtrace, developers
should consider using valgrind. As a replacement for the hook
functions, developers can interpose their own malloc implementation.
Plus removal of the documentation of the hook functions from the manual
(if there is anything left).
In any case, I'll submit a separate patch for documenting the malloc
interposition feature (bug 20424).
Thanks,
Florian
next prev parent reply other threads:[~2016-11-15 13:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-26 15:02 Florian Weimer
2016-10-26 15:55 ` Joseph Myers
2016-11-15 13:22 ` Florian Weimer [this message]
2016-11-15 15:39 ` Joseph Myers
2016-11-15 15:56 ` Florian Weimer
2016-11-16 1:37 ` Joseph Myers
2016-11-16 9:46 ` Will Newton
2016-11-17 13:00 ` Florian Weimer
2016-11-17 14:27 ` Joseph Myers
2016-11-17 14:50 ` Steve Vormwald
2016-11-17 16:08 ` Adhemerval Zanella
2016-11-18 9:13 ` Florian Weimer
2016-11-18 17:29 ` Steve Vormwald
2016-11-21 19:43 ` DJ Delorie
2016-11-22 15:12 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=11f59117-e5a4-4c62-739c-e05e01ee43b3@redhat.com \
--to=fweimer@redhat.com \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).