From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16721 invoked by alias); 5 May 2003 14:24:47 -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 16714 invoked from network); 5 May 2003 14:24:47 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 5 May 2003 14:24:47 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 30BEA2B2F; Mon, 5 May 2003 10:24:44 -0400 (EDT) Message-ID: <3EB6742C.6070409@redhat.com> Date: Mon, 05 May 2003 14:24:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH/i386newframe/RFC] DWARF CFI frame unwinder References: <200305042207.h44M7gNG023734@elgar.kettenis.dyndns.org> <3EB5DBFF.6030009@redhat.com> <200305051348.h45DmHC1009293@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00062.txt.bz2 > Date: Sun, 04 May 2003 23:35:27 -0400 > From: Andrew Cagney > > Mark, fyi, > > > + case REG_SAVED_REG: > > + *optimizedp = 0; > > + *lvalp = lval_register; > > + *addrp = 0; > > + *realnump = DWARF2_REG_TO_REGNUM (cache->reg[regnum].loc.reg); > > + if (valuep) > > + { > > + /* Read the value from the register. */ > > + frame_unwind_register (next_frame, *realnump, valuep); > > + } > > + break; > > + > > Set *addrp to the register offset hack (Otherwize something mysterious > fails. What? I don't remember). > > Yes, findvar.c:value_of_register() and findvar.c:value_from_register() > use this. Worse, our whole value subsystem seems to rely on this. > Ughh, that's really gross. We should do something about that! [tell me about it :-)] > Anyway. Thinking about it a bit more, I suspect the whole handling of > REG_SAVED_REG is wrong. Instead, we should just change the register > number according to the DWARF CFI rule and let the unwinder for > NEXT_FRAME handle the request: > > case REG_SAVED_REG: > regnum = DWARF2_REG_TO_REGNUM (cache->reg[regnum].loc.reg); > /* FALLTHROUGH */ Please, anything but a fallthrough :-) > case REG_UNMODIFIED: > frame_register_unwind (next_frame, regnum, > optimizedp, lvalp, addrp, realnump, valuep); > break; > > Eventually this means that sentinel_frame_prev_register will provide > the register offset hack. > > Do you agree with my analysis? Yes. Stores could otherwize go to the wrong register (a really horrible bug to track down). I should note that the part of ``info registers'' where it prints out where a register was saved needs a re-think. Now that things are recursive it has the potential for reporting a register that was saved N levels further in on the stack (it does this already with the d10v and PC vs LR). BTW, suggest adding a few name prefixes to register number variables - it is really hard to know which space (DWARF 2 or GDB) the register's value falls in. Andrew