This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]