From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40733 invoked by alias); 24 Aug 2017 09:27:55 -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 33216 invoked by uid 89); 24 Aug 2017 09:26:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no 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; Thu, 24 Aug 2017 09:26:36 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1F3C7C047B78; Thu, 24 Aug 2017 09:26:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1F3C7C047B78 Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=palves@redhat.com 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 2F6EF77D5D; Thu, 24 Aug 2017 09:26:33 +0000 (UTC) Subject: Re: [PATCH v2] gdbserver: linux_low: elf_64_file_p cache results To: jon@ringle.org, gdb-patches@sourceware.org References: <1503549910-24770-1-git-send-email-jon@ringle.org> Cc: Jon Ringle From: Pedro Alves Message-ID: <402cb282-9cd1-2725-f6de-ec5f9eb15e0d@redhat.com> Date: Thu, 24 Aug 2017 09:27: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: <1503549910-24770-1-git-send-email-jon@ringle.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-08/txt/msg00461.txt.bz2 Hi Jon, On 08/24/2017 05:45 AM, jon@ringle.org wrote: > The problem lied in the fact that the function elf_64_file_p() (call on > line 7184), was returning -1 because it could not open the file (with errno > set to EACCESS). This was because the inferior's code was dropping root > privileges and no longer was able to read the file. I feel like I'm missing something. If it's the inferior that is dropping privileges, how can that affect gdbserver? It's gdbserver that opens the file, not the inferior. It'd be nice to have a testcase for this. Would it be possible to come up with a small reproducer? > This patch implements a cache per file in the elf_64_file_p() function so > that it remembers the results of a previous query for the same filename. > > Since it seems that c++ is now accepted in gdb, the cache was implemented > using std::map Doesn't look correct, since it assumes that the 64-bit-ness of "/proc/PID/exe" stays constant for the lifetime of gdbserver, which is certainly false. With "gdbserver --multi", a single gdbserver can stay around debugging multiple processes for an undeterminate amount of time. After the current process PID exits, nothing prevents the kernel from reusing PID for another process. Also, we need to clear the cache when the inferior process execs, since a 32-bit process can well exec a 64-bit process, and vice-versa. If caching is the right approach, then it seems to me that it'd be much simpler/efficient to make it a new 'bool is_elf64;' field of struct process_info_private. Thanks, Pedro Alves