From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54864 invoked by alias); 28 Nov 2017 16:21:48 -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 54658 invoked by uid 89); 28 Nov 2017 16:21:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KB_WAM_FROM_NAME_SINGLEWORD,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=You've, Youve, honour 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, 28 Nov 2017 16:21:46 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A075276525 for ; Tue, 28 Nov 2017 16:21:45 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4BA4A5D6B7; Tue, 28 Nov 2017 16:21:37 +0000 (UTC) Subject: Re: [PATCH 1/4] Implement 'set honor-dontdump-flag' command To: Sergio Durigan Junior , Sergio Lopez References: <20171128132148.31802-1-slp@redhat.com> <20171128132148.31802-2-slp@redhat.com> <87induo1ey.fsf@redhat.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Tue, 28 Nov 2017 16:21: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: <87induo1ey.fsf@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-11/txt/msg00735.txt.bz2 On 11/28/2017 03:42 PM, Sergio Durigan Junior wrote: >> @@ -2517,4 +2522,16 @@ of /proc/PID/coredump_filter when generating the corefile. For more information >> about this file, refer to the manpage of core(5)."), >> NULL, show_use_coredump_filter, >> &setlist, &showlist); >> + >> + add_setshow_boolean_cmd ("honor-dontdump-flag", class_files, >> + &honor_dontdump_flag, _("\ >> +Set whether gcore should honor the VM_DONTDUMP flag."), >> + _("\ >> +Show whether gcore should honor the VM_DONTDUMP flag."), >> + _("\ >> +Use this command to set whether gcore should honor the VM_DONTDUMP\n\ >> +flag from /proc/PID/smaps when generating the corefile. For more information\n\ >> +about this file, refer to the manpage of proc(5) and core(5)."), >> + NULL, show_use_coredump_filter, > > You've already spotted the mistake of using 'show_use_coredump_filter' > here. > >> + &setlist, &showlist); > > I'm not sure "honor-dontdump-flag" is a good name for this setting. > There's no indication that it relates to coredumps, and I think it > should. A name like "honor-coredump-dontdump-flag" is a bit repetitive, > but IMHO is better than just "honor-dontdump-flag". WDYT? Personally, I don't find the "coredump" issue that much of a problem, given "dump" is there. "honor-coredump-dontdump" looks like a mouthful to me. I think using "ignore" in the name would some more natural in GDB than "honor". I.e., "set ignore-dontdump-flag on/off". That mean default is off/0 ( and the control variable could go to .bss :-) ) It also avoids our UK friends cursing at bad spelling of "honour". :-) "set dump-excluded-mappings on/off" could work too? I skimmed the series and didn't find a gdb/NEWS entry; we need one for new commands. > > To be fair, my first thought was to suggest adding a new "set coredump" > super command, which would encompass "set coredump use-coredump-filter" > and "set coredump honor-dontdump-flag", but I wouldn't like to introduce > this change so close to a release. > > Otherwise, the patch looks OK to me, but I'm not a global maintainer. > Thanks, Pedro Alves