From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124350 invoked by alias); 12 Mar 2015 15:02:17 -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 124341 invoked by uid 89); 12 Mar 2015 15:02:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 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 15:02:15 +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 t2CF2CEq009355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 12 Mar 2015 11:02:13 -0400 Received: from tranklukator.brq.redhat.com (dhcp-1-208.brq.redhat.com [10.34.1.208]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id t2CF2AbK021917; Thu, 12 Mar 2015 11:02:11 -0400 Received: by tranklukator.brq.redhat.com (nbSMTP-1.00) for uid 500 oleg@redhat.com; Thu, 12 Mar 2015 16:00:26 +0100 (CET) Date: Thu, 12 Mar 2015 15:02:00 -0000 From: Oleg Nesterov To: Jan Kratochvil Cc: Sergio Durigan Junior , GDB Patches , Pedro Alves Subject: Re: [PATCH] Improve corefile generation by using /proc/PID/coredump_filter (PR corefile/16902) Message-ID: <20150312150024.GA4817@redhat.com> References: <878ufc9kau.fsf@redhat.com> <20150305154827.GA9441@host1.jankratochvil.net> <87zj7r5fpz.fsf@redhat.com> <20150305205744.GA13165@host1.jankratochvil.net> <20150311200052.GA22654@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150311200052.GA22654@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2015-03/txt/msg00339.txt.bz2 See another email I sent, perhaps this needs more discussion... But, On 03/11, Oleg Nesterov wrote: > > On 03/05, Jan Kratochvil wrote: > > > > On Thu, 05 Mar 2015 21:52:56 +0100, Sergio Durigan Junior wrote: > > > On Thursday, March 05 2015, Jan Kratochvil wrote: > > > > On Thu, 05 Mar 2015 04:48:09 +0100, Sergio Durigan Junior wrote: > > > > Currently it also tries to dump [vvar] (by default rules) but that is > > > > unreadable for some reason, causing: > > > > warning: Memory read failed for corefile section, 8192 bytes at 0x7ffff6ceb000. > > > > ^^^^^^^^^^^^^^ > > > > Saved corefile /tmp/1j > > > > (gdb) _ > > > > # grep 7ffff6ceb000 /proc/$p/maps > > > > 7ffff6ceb000-7ffff6ced000 r--p 00000000 00:00 0 [vvar] > > > > ^^^^^^^^^^^^ ^^^^ > > > > > > > > I do not know what [vvar] is good for and why it cannot be read. > > Probably gdb doesn't need to dump this vma, but see below. Probably yes. Note that it has VM_DONTDUMP ("dd" in "VmFlags:" field). 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. (just in case, "vdso" is the same too but it is MAYWRITE, so it can have anonymous pages. Say, breakpoints installed by gdb). Oleg.