From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45855 invoked by alias); 12 Mar 2015 17:37:31 -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 45841 invoked by uid 89); 12 Mar 2015 17:37:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 12 Mar 2015 17:37:28 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2CHbQfF011948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 12 Mar 2015 13:37:26 -0400 Received: from localhost (dhcp-10-15-16-169.yyz.redhat.com [10.15.16.169]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2CHbPjs032365 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Thu, 12 Mar 2015 13:37:26 -0400 From: Sergio Durigan Junior To: Oleg Nesterov Cc: Jan Kratochvil , GDB Patches , Pedro Alves Subject: Re: [PATCH] Improve corefile generation by using /proc/PID/coredump_filter (PR corefile/16902) References: <878ufc9kau.fsf@redhat.com> <20150305154827.GA9441@host1.jankratochvil.net> <87zj7r5fpz.fsf@redhat.com> <20150305205744.GA13165@host1.jankratochvil.net> <20150311200052.GA22654@redhat.com> <20150312150024.GA4817@redhat.com> X-URL: http://blog.sergiodj.net Date: Thu, 12 Mar 2015 17:37:00 -0000 In-Reply-To: <20150312150024.GA4817@redhat.com> (Oleg Nesterov's message of "Thu, 12 Mar 2015 16:00:24 +0100") Message-ID: <878uf2p162.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00355.txt.bz2 On Thursday, March 12 2015, Oleg Nesterov wrote: >> Probably gdb doesn't need to dump this vma, but see below. > > Probably yes. Note that it has VM_DONTDUMP ("dd" in "VmFlags:" field). The fact that the region has VM_DONTDUMP is enough for GDB to ignore it. IMO, as discussed in the other thread with Andy, the Linux kernel is bogus in this case and should also be ignoring this. > However. If (for any reason) you decide to dump this region, gdb can > look into /proc/self/maps, find its own "vvar" mapping, and simply read > this memory. Unlike "vdso", "vvar" has the same content for every process. Yeah, but I don't think this is worth the effort. As Pedro mentioned, things can get more complicated when we consider remote scenarios. > (just in case, "vdso" is the same too but it is MAYWRITE, so it can have > anonymous pages. Say, breakpoints installed by gdb). Also, [vdso] doesn't have the VM_DONTDUMP flag. My patch is already dumping it inconditionally. -- Sergio GPG key ID: 0x65FC5E36 Please send encrypted e-mail if possible http://sergiodj.net/