From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4348 invoked by alias); 22 Oct 2003 19:38:00 -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 4339 invoked from network); 22 Oct 2003 19:37:59 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 22 Oct 2003 19:37:59 -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 h9MJbvM10753 for ; Wed, 22 Oct 2003 15:37:57 -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 h9MJbur29973; Wed, 22 Oct 2003 15:37:56 -0400 Received: from localhost.localdomain (vpn50-2.rdu.redhat.com [172.16.50.2]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id h9MJbrhw002711; Wed, 22 Oct 2003 15:37:54 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h9MJbl931625; Wed, 22 Oct 2003 12:37:47 -0700 Date: Wed, 22 Oct 2003 19:38:00 -0000 From: Kevin Buettner Message-Id: <1031022193747.ZM31624@localhost.localdomain> In-Reply-To: "J. Johnston" "Re: RFA: ia64 tdep patch" (Oct 21, 7:03pm) References: <3F9049EF.8060209@redhat.com> <1031020201315.ZM20659@localhost.localdomain> <3F9459B6.5000909@redhat.com> <1031021222239.ZM26261@localhost.localdomain> <3F95BB43.1040703@redhat.com> To: "J. Johnston" , Kevin Buettner Subject: Re: RFA: ia64 tdep patch Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00656.txt.bz2 On Oct 21, 7:03pm, J. Johnston wrote: > You're looking at my old ChangeLog. I've looked at your most recent patch, but do not see the new ChangeLog entry. Would you mind posting it? > > The code (below) in ia64_sigtramp_frame_prev_register() which computes > > PSR doesn't look right to me. Could you check it? (If it is right, > > please explain it...) > > I'll explain my logic. As you know, the VRAP address is the return address. > AFAICT by reading the ABI and insn set, there is no information about what the > return address is set to when the branch is in slot 0 or 1 (i.e. is the return > address the next bundle or the next slot?). The ip register isn't supposed to > contain the slot number; it is encoded in the PSR register. When gdb gets the > pc value, it forms it by unwinding the PSR and IP registers - getting the slot > number from the PSR and the IP register address to form a virtual pc address. I > did not want to get the slot number wrong if it was encoded in the return > address so this is why I masked it off above. The PSR register is only used by > gdb in unwinding the pc. Thanks for the explanation. Could you please add a brief comment to the code. > > Regarding this hunk of code in ia64_sigtramp_frame_prev_register()... > > > > + else if ((regnum >= IA64_GR32_REGNUM && regnum <= IA64_GR127_REGNUM) || > > + (regnum >= V32_REGNUM && regnum <= V127_REGNUM)) > > + { > > + CORE_ADDR addr = 0; > > + if (regnum >= V32_REGNUM) > > + regnum = IA64_GR32_REGNUM + (regnum - V32_REGNUM); > > + addr = cache->saved_regs[regnum]; > > + if (addr != 0) > > + { > > + *lvalp = lval_memory; > > + *addrp = addr; > > + read_memory (addr, valuep, register_size (current_gdbarch, regnum)); > > + } > > + } > > > > Could you add a comment explaining why the normal method of computing > > V32 (via ia64_pseudo_register_read()) is inadequate? > > I don't know. I had this for safety reasons already in the > ia64_frame_prev_register() because I didn't know if it might be > called with the pseudo register number or not. This code was > copied. Should it be removed in both places? I don't know. I've been studying the code and am wondering why the V32 ... V127 pseudo regs were introduced at all. Could you remind me of the reason? > > Hmm... doesn't this hunk of code also need to be concerned with > > register renames? (I.e, the rotating register stuff...) I'm > > wondering why the floating point registers need it, but the > > GRs don't. > > > > This code was copied from ia64_frame_prev_register() as it used to be called to > do the underlying work. > > The stuff at the end of examine_prologue() handles rotating GRs for > the normal case but doesn't for floating point registers. I would > doubt very much that the signal trampoline uses rotating registers > so I probably should remove it for the floating-point case. I think you're probably right. It'd be nice though if we could arrange for the code which handles rotating registers for floating point and general regs to appear in the same function. (This can happen in a different patch though.) Kevin