This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Use of mcheck during GDB development
- From: Pedro Alves <palves at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>, gdb-patches at sourceware dot org
- Date: Tue, 15 Nov 2016 20:03:45 +0000
- Subject: Re: Use of mcheck during GDB development
- Authentication-results: sourceware.org; auth=none
- References: <aa753ffe-bfa9-c9b1-f55c-ccfc498c4014@redhat.com>
On 11/15/2016 04:00 PM, Florian Weimer wrote:
> We need to get rid of the mcheck functionality in glibc because we
> really, really want to stop calling the malloc hook functions.
>
> A future glibc version will provide a lightweight heap checker, with
> functionality comparable to mcheck (but thread-safe!) as linkable and
> LD_PRELOAD-able (perhaps under a different name than libmcheck).
>
> How critical is the mcheck functionality to GDB development?
Despite its flaws, it catches bugs. It's lightweight enough that
it can be on all the time. It's nice to have, IMO.
> Would it
> be a problem if next glibc release would issue a deprecation warning
> without actually having a suitable replacement in-tree?
Will that cause build problems with -Werror?
> I want to get the deprecation notice out as soon as possible, but I
> might not be able to finish the mcheck replacement in time for the next
> glibc release.
If there's no replacement that users can move to, what's the point
of warning soon? Is there an advantage vs only when the replacement
exists?
Thanks,
Pedro Alves