This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Use of mcheck during GDB development
On 11/15/2016 09:03 PM, Pedro Alves wrote:
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.
Interesting. Do you know which mcheck bits actually catch failures?
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 don't know. As far as I can tell, you just link with -lmcheck. This
should give you at most a link-time warning, which wouldn't fail the build.
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?
We can incorporate feedback from existing users into the design of the
replacement. We wouldn't be having this conversation if I didn't
announce my intent to deprecate without immediate replacement from the
glibc side.
I think most people use valgrind for memory debugging.
Thanks,
Florian