From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50153 invoked by alias); 15 Nov 2016 20:03:50 -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 49842 invoked by uid 89); 15 Nov 2016 20:03:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.7 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= 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:03:48 +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 147C77D0EF for ; Tue, 15 Nov 2016 20:03:47 +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 uAFK3jTU032220; Tue, 15 Nov 2016 15:03:46 -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:03: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/msg00395.txt.bz2 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