From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95723 invoked by alias); 12 Mar 2015 16:07:42 -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 94181 invoked by uid 89); 12 Mar 2015 16:07:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.9 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 16:07:40 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2CG7dAh011773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 12 Mar 2015 12:07:39 -0400 Received: from tranklukator.brq.redhat.com (dhcp-1-208.brq.redhat.com [10.34.1.208]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id t2CG7bg7025185; Thu, 12 Mar 2015 12:07:38 -0400 Received: by tranklukator.brq.redhat.com (nbSMTP-1.00) for uid 500 oleg@redhat.com; Thu, 12 Mar 2015 17:05:53 +0100 (CET) Date: Thu, 12 Mar 2015 16:07:00 -0000 From: Oleg Nesterov To: Pedro Alves Cc: Jan Kratochvil , Sergio Durigan Junior , GDB Patches Subject: Re: [PATCH] Improve corefile generation by using /proc/PID/coredump_filter (PR corefile/16902) Message-ID: <20150312160551.GA8144@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> <20150312150024.GA4817@redhat.com> <5501B48B.7060802@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5501B48B.7060802@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2015-03/txt/msg00344.txt.bz2 On 03/12, Pedro Alves wrote: > > On 03/12/2015 03:00 PM, Oleg Nesterov wrote: > > > 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. > > Actually it can't: GDB may well be dumping the memory of > a process running on another machine (through gdbserver). Yes, thanks for correcting me... I do not know if gdb can ask gdbserver to read its own memory, but even if it can this doesn't look like a nice solution. Just curious... I know that gdb can execute the code on behalf of the traced process, so perhaps it can force the tracee to memcpy() its "vvar" memory. Can this work with gdbserver? Again, I do not think this hack can make any sense. I am just curious. At least (I hope) this mapping doesn't look "important" from debugging pov, perhaps gdb should ignore it. Lets see what Andy thinks, but I bet it is very unlikely that the kernel will be changed to allow the access to this vma. Oleg.