From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31884 invoked by alias); 29 Jan 2003 06:54:51 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 31874 invoked from network); 29 Jan 2003 06:54:49 -0000 Received: from unknown (HELO www.lampret.com) (193.189.173.98) by 172.16.49.205 with SMTP; 29 Jan 2003 06:54:49 -0000 Received: from vili (support.flextronics.si [212.118.94.130]) by www.lampret.com (8.11.6/8.11.6) with ESMTP id h0T9dVB17756; Wed, 29 Jan 2003 08:39:36 -0100 Content-Type: text/plain; charset="iso-8859-1" From: Marko Mlinar To: Andrew Cagney Subject: Re: OC? Date: Wed, 29 Jan 2003 06:54:00 -0000 User-Agent: KMail/1.4.1 Cc: gdb-patches@sources.redhat.com References: <3DF6642E.7020700@redhat.com> <200301150929.15118.markom@opencores.org> <3E36DDBD.9000108@redhat.com> In-Reply-To: <3E36DDBD.9000108@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200301290803.13751.markom@opencores.org> X-SW-Source: 2003-01/txt/msg00769.txt.bz2 On Tuesday 28 January 2003 20:45, Andrew Cagney wrote: > > Hi Andrew! > > > >> Turns out this has been done. > >> > >> > We have also problems with registers. You were saying something that > >> > we should move all the registers (we have 8k+ registers with generat= ed > >> > names) into the temporary storage (I hope all these won't get cached > >> > in the host...). > > 8k * 8 bytes ~=3D 64k. > > Either that all lives in the text segment, or it is only allocated when > all the names are asked for. Andrew, I was referring more to register transfer. Most of the registers should not= be=20 chached at all -- the value read from these special purpose registers (SPRs= )=20 can differ in time/access. Some registers may also have clear-after-read,=20 FIFO implemented or any other obscure functionality. It would be nice if all names would be generated, instead of storing their= =20 names, however I suppose nobody with our target will complain about high=20 memory usage. Another problem is with printing it out and displaying. Unfortunatelly I do= n't=20 know how exaclty the remote debuggers work (we mostly use DDD), but if they= =20 try to read all registers when e.g. they reach breakpoint -- it will break= =20 the target (because e.g. clear-after-read). And besides it may take a while= =20 to load them all in. > >> Yes. A gui for instance will likely want access to all names at once. > > > > I tried to fix this issue, but there were not enough documentation nor > > such targets for me to dig through. Is it possible that you (or somebody > > else) change this please? > > I'm not sure what the problem is. Just wrap the current code in > something that maintains a table of previously returned names. I don't know a lot of internals, which are common knowledge for most here, = and=20 I didn't know if my solutions would solve all above issues. thanks, Marko