From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13100 invoked by alias); 25 Aug 2003 18:12:24 -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 13029 invoked from network); 25 Aug 2003 18:12:12 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 25 Aug 2003 18:12:12 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 79FC0800340; Mon, 25 Aug 2003 14:12:11 -0400 (EDT) Message-ID: <3F4A517B.3070506@redhat.com> Date: Mon, 25 Aug 2003 18:12: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> In-Reply-To: <1030822214626.ZM6354@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-08/txt/msg00435.txt.bz2 Kevin Buettner wrote: > Hi Jeff, > > Sorry for taking so long on your patch... > > On Aug 8, 1:32pm, J. Johnston wrote: > > >>@@ -113,18 +120,18 @@ >> "r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15", >> "r16", "r17", "r18", "r19", "r20", "r21", "r22", "r23", >> "r24", "r25", "r26", "r27", "r28", "r29", "r30", "r31", >>- "r32", "r33", "r34", "r35", "r36", "r37", "r38", "r39", >>- "r40", "r41", "r42", "r43", "r44", "r45", "r46", "r47", >>- "r48", "r49", "r50", "r51", "r52", "r53", "r54", "r55", >>- "r56", "r57", "r58", "r59", "r60", "r61", "r62", "r63", >>- "r64", "r65", "r66", "r67", "r68", "r69", "r70", "r71", >>- "r72", "r73", "r74", "r75", "r76", "r77", "r78", "r79", >>- "r80", "r81", "r82", "r83", "r84", "r85", "r86", "r87", >>- "r88", "r89", "r90", "r91", "r92", "r93", "r94", "r95", >>- "r96", "r97", "r98", "r99", "r100", "r101", "r102", "r103", >>- "r104", "r105", "r106", "r107", "r108", "r109", "r110", "r111", >>- "r112", "r113", "r114", "r115", "r116", "r117", "r118", "r119", >>- "r120", "r121", "r122", "r123", "r124", "r125", "r126", "r127", >>+ "", "", "", "", "", "", "", "", >>+ "", "", "", "", "", "", "", "", >>+ "", "", "", "", "", "", "", "", >>+ "", "", "", "", "", "", "", "", >>+ "", "", "", "", "", "", "", "", >>+ "", "", "", "", "", "", "", "", >>+ "", "", "", "", "", "", "", "", >>+ "", "", "", "", "", "", "", "", >>+ "", "", "", "", "", "", "", "", >>+ "", "", "", "", "", "", "", "", >>+ "", "", "", "", "", "", "", "", >>+ "", "", "", "", "", "", "", "", > > > 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. > Now with regards to struct ia64_frame_cache... > > +struct ia64_frame_cache > +{ > + /* Base address. */ > + CORE_ADDR base; > + CORE_ADDR pc; > + CORE_ADDR saved_sp; > > Could you (better) document the above three fields? > Not a problem. > .... > > 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? -- Jeff J. > Kevin >