From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28023 invoked by alias); 25 Aug 2003 23:29:32 -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 28016 invoked from network); 25 Aug 2003 23:29:31 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 25 Aug 2003 23:29:31 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 9A579800348; Mon, 25 Aug 2003 19:29:30 -0400 (EDT) Message-ID: <3F4A9BDA.9030706@redhat.com> Date: Mon, 25 Aug 2003 23:29:00 -0000 From: "J. Johnston" Organization: Red Hat Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: modernization of ia64-tdep.c with new frame model for gdb-6.0 branch References: <3F283061.4060007@redhat.com> <3F33DEB5.1090202@redhat.com> <1030822214626.ZM6354@localhost.localdomain> <3F4A517B.3070506@redhat.com> <1030825184133.ZM9803@localhost.localdomain> In-Reply-To: <1030825184133.ZM9803@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-08/txt/msg00442.txt.bz2 Kevin Buettner wrote: > On Aug 25, 2:12pm, J. Johnston wrote: > > >>Kevin Buettner wrote: > > >>>Okay, I see that you're turning r32-r127 and (not shown) p0-p64 >>>into pseudo registers. Is there any reason to leave big "holes" >>>in the register number space? I.e, why not just get rid of all >>>of the empty strings above? >>> >>>(Most of the time, the reason NOT to do this is because remote >>>targets depend on the order. The only remote target that I'm >>>aware of is gdbserver, and I'm not particularly worried about >>>breaking compatibility.) >>> >>>If I'm not mistaken, removing these holes will somewhat decrease >>>the size of struct ia64_frame_cache: >>> >>> +struct ia64_frame_cache >>> +{ >>> ... >>> + /* Saved registers. */ >>> + CORE_ADDR saved_regs[NUM_IA64_RAW_REGS]; >>> + >>> +}; >>> >> >>Actually, number of real raw registers went down to the last non-pseudo >>register anyway. My preference regarding renumbering registers would be >>to sync this up with gdbserver later. > > > Okay, so long as "later" isn't too much later. It'd be a shame if someone > suddenly wrote a stub which depended on the holes being there... > > >>>Have you tested the nat bit related code in ia64_pseudo_register_read() >>>and ia64_pseudo_register_write() ? My recollection is that my original >>>code didn't handle the unat bits correctly. I was wondering if you >>>had fixed this problem. (I'm curious about the other NaT bits too.) >>> >> >>Could you elaborate about what problems you think existed in the previous >>code? > > > I'll send you a thread which describes the problems. After rereading > that thread, it looks like the fix isn't as difficult as I had > remembered. In fact, it should be pretty easy. (But it still needs > to be tested.) > > With regard to your current patch, I'm okay with you checking it in > after adding the ia64_frame_cache comments. > > Thanks for doing these cleanups. > > Kevin > Thanks Kevin. Patch is checked in with comments added. -- Jeff J.