From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21089 invoked by alias); 22 Aug 2003 21:46:35 -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 21082 invoked from network); 22 Aug 2003 21:46:34 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 22 Aug 2003 21:46:34 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h7MLkYl11928 for ; Fri, 22 Aug 2003 17:46:34 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h7MLkXs21889; Fri, 22 Aug 2003 17:46:33 -0400 Received: from localhost.localdomain (vpn50-17.rdu.redhat.com [172.16.50.17]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id h7MLkWHq006118; Fri, 22 Aug 2003 17:46:32 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h7MLkRc06355; Fri, 22 Aug 2003 14:46:27 -0700 Date: Fri, 22 Aug 2003 21:46:00 -0000 From: Kevin Buettner Message-Id: <1030822214626.ZM6354@localhost.localdomain> In-Reply-To: "J. Johnston" "Re: RFA: modernization of ia64-tdep.c with new frame model for gdb-6.0 branch" (Aug 8, 1:32pm) References: <3F283061.4060007@redhat.com> <3F33DEB5.1090202@redhat.com> To: "J. Johnston" Subject: Re: RFA: modernization of ia64-tdep.c with new frame model for gdb-6.0 branch Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-08/txt/msg00408.txt.bz2 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]; + +}; 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? .... 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.) Kevin