From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15545 invoked by alias); 10 Jul 2009 09:29:21 -0000 Received: (qmail 15537 invoked by uid 22791); 10 Jul 2009 09:29:20 -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; Fri, 10 Jul 2009 09:29:12 +0000 Received: (qmail 12438 invoked from network); 10 Jul 2009 09:29:10 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Jul 2009 09:29:10 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFA] Use data cache for stack accesses Date: Fri, 10 Jul 2009 09:34:00 -0000 User-Agent: KMail/1.9.10 Cc: Daniel Jacobowitz , Jacob Potter References: <7e6c8d660907081308r13bff580rdcf4822c77df8403@mail.gmail.com> <20090708205140.GA2926@caradoc.them.org> <200907082158.44386.pedro@codesourcery.com> In-Reply-To: <200907082158.44386.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200907101029.12135.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/msg00303.txt.bz2 On Wednesday 08 July 2009 21:58:44, Pedro Alves wrote: > 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. =A0 > > I don't like baking knowledge into other modules=20 > > of GDB that they can extract the PID and use it to key per-inferior > > data. > >=20 > > Or just add it to struct inferior? To complete a thought: if not adding a generic inferior_data so that modules can put whatever they want there, then putting a new member on struct inferior exposes some module's internal detail to the rest of GDB. I'm not sure I like that better either. Note that we always get the inferior from the pid (it's mostly unavoidable,=20 we need a way to map a target reported pid to an internal inferior). Even current_inferior() does that. > 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,=20 Forgot to be explicit on a real, current, example of this: debugging parent/child vforks. > so we could share a cache between them, but,=20=20 > 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. >=20 > I don't have a problem with adding this to struct inferior for now, > it just seemed premature. >=20 Actually, I think that if you make it per-inferior, and *don't flush it when switching inferiors*, making it per-inferior introduces a bug visible when debugging vforks. Say: stay attached to both parent/child, get a backtrace when selecting the child; switch to the parent, change some piece of memory that would be in the parent's stack dcache; switch back to parent, and observe that the stack cache is now stale. --=20 Pedro Alves