From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15374 invoked by alias); 14 Mar 2003 11:54: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 15320 invoked from network); 14 Mar 2003 11:54:34 -0000 Received: from unknown (HELO kerberos.suse.cz) (195.47.106.10) by sources.redhat.com with SMTP; 14 Mar 2003 11:54:34 -0000 Received: from chimera.suse.cz (chimera.suse.cz [10.20.0.2]) by kerberos.suse.cz (SuSE SMTP server) with ESMTP id E861B59D3E2; Fri, 14 Mar 2003 12:54:33 +0100 (CET) Received: from suse.cz (naga.suse.cz [10.20.1.16]) by chimera.suse.cz (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h2EBsX406984; Fri, 14 Mar 2003 12:54:33 +0100 X-Authentication-Warning: chimera.suse.cz: Host naga.suse.cz [10.20.1.16] claimed to be suse.cz Message-ID: <3E71C2F9.3060504@suse.cz> Date: Fri, 14 Mar 2003 11:54:00 -0000 From: Michal Ludvig Organization: SuSE CR User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: cs, cz, en MIME-Version: 1.0 To: Andrew Cagney Cc: Mark Kettenis , GDB Patches Subject: Re: [offbyone RFC] Merge i386newframe References: <3E6FAF64.7070304@suse.cz> <3E70D673.1040504@redhat.com> In-Reply-To: <3E70D673.1040504@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00316.txt.bz2 Andrew Cagney wrote: >> Hi Andrew, >> this patch is a merge of Mark's i386newframe-branch to your >> offbyone-branch. It works quite well, unwinds through signal frames >> and frameless functions, but still has some strange regressions that >> aren't present in i386newframe branch. >> >> For example this program: >> int var; >> void foo () >> { >> var = 0x1234; >> } >> int main () >> { >> foo (); >> return 0; >> } >> >> Running it in the GDB: >> (gdb) b main >> Breakpoint 1 at 0x804832c: file tst.c, line 8. >> (gdb) r >> Starting program: tst >> >> Breakpoint 1, main () at tst.c:8 >> 8 foo (); >> (gdb) n > > > I suspect Daniel's answered this. The frame ID needs to be constant > through out the lifetime of the frame. Getting that right isn't > trivial. However, getting it right can receive a bonus: d10v now > passing mips_pro.exp. You mean the whole ID should be constant or just id.base? If id.pc must be constant as well, it couldn't represent the PC register anymore... I'm confused. Michal Ludvig -- * SuSE CR, s.r.o * mludvig@suse.cz * (+420) 296.545.373 * http://www.suse.cz