From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90425 invoked by alias); 15 Nov 2016 20:50:21 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 90396 invoked by uid 89); 15 Nov 2016 20:50:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=everyday X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 15 Nov 2016 20:50:09 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0913325CD5 for ; Tue, 15 Nov 2016 20:50:08 +0000 (UTC) Received: from [127.0.0.1] (ovpn03.gateway.prod.ext.phx2.redhat.com [10.5.9.3]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAFKo6mF006417; Tue, 15 Nov 2016 15:50:07 -0500 Subject: Re: Use of mcheck during GDB development To: Florian Weimer , gdb-patches@sourceware.org References: From: Pedro Alves Message-ID: Date: Tue, 15 Nov 2016 20:50:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00398.txt.bz2 On 11/15/2016 08:22 PM, Florian Weimer wrote: > 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? Here's an example: https://sourceware.org/ml/gdb-patches/2016-03/msg00125.html > >>> 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. OK. In that case, it doesn't make a difference for us whatever you decide to do. We have a --enable-libmcheck configure switch already. Worse that'll happen is that we'll switch the default to off. It's already off by default for most developers, because mcheck is incompatible with Python+threads (see gdb/configure.ac). >>> 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 definitely appreciate you reaching out. I was wondering about the point of a warning at compile/build time, not about deprecation notice via NEWS/email etc. Maybe a compile/link warning in advance will make projects add configure switches to disable mcheck if they don't have them (though I doubt there's such a case). Anyway, it's just a checker; if it goes away at some point because no one wants to support it, then we'll just have to stop enabling it. > > I think most people use valgrind for memory debugging. Yeah, or address sanitizer, which would be closer to being something you could always have on. Valgrind is too heavyweight for everyday use. I believe we're not asan clean yet, unfortunately, but we're slowly getting there. Thanks, Pedro Alves