From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7406 invoked by alias); 8 Jul 2009 20:58:49 -0000 Received: (qmail 7396 invoked by uid 22791); 8 Jul 2009 20:58:49 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 08 Jul 2009 20:58:42 +0000 Received: (qmail 32707 invoked from network); 8 Jul 2009 20:58:41 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 8 Jul 2009 20:58:41 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFA] Use data cache for stack accesses Date: Thu, 09 Jul 2009 03:06:00 -0000 User-Agent: KMail/1.9.10 Cc: Daniel Jacobowitz , Jacob Potter References: <7e6c8d660907081308r13bff580rdcf4822c77df8403@mail.gmail.com> <200907082146.40513.pedro@codesourcery.com> <20090708205140.GA2926@caradoc.them.org> In-Reply-To: <20090708205140.GA2926@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200907082158.44386.pedro@codesourcery.com> X-IsSubscribed: yes 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 X-SW-Source: 2009-07/txt/msg00275.txt.bz2 On Wednesday 08 July 2009 21:51:40, Daniel Jacobowitz wrote: > Or could we store a dcache per-inferior? =A0Jacob's right - I thought > there was an 'inferior_data' to store arbitrary data per-inferior, > but there isn't. =A0I don't like baking knowledge into other modules > of GDB that they can extract the PID and use it to key per-inferior > data. >=20 > Or just add it to struct inferior? >=20 The reason I didn't suggest that is that we don't have an address space object --- yet. My multi-exec patches add one, and there's a similar mechanism to per-objfile data where we can do things like these. More than one inferior can share the same address space, so we could share a cache between them, but, if the cache if write-through, it won't be a big problem if we don't --- it would be if it was left as writeback. I don't have a problem with adding this to struct inferior for now, it just seemed premature. --=20 Pedro Alves