From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2777 invoked by alias); 26 Feb 2003 01:20:08 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 2768 invoked from network); 26 Feb 2003 01:20:07 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by 172.16.49.205 with SMTP; 26 Feb 2003 01:20:07 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id h1Q1K6g15139; Tue, 25 Feb 2003 19:20:06 -0600 Date: Wed, 26 Feb 2003 01:20:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200302260120.h1Q1K6g15139@duracef.shout.net> To: ac131313@redhat.com, gdb@sources.redhat.com Subject: Re: Identifying a dummy frame using a frame id X-SW-Source: 2003-02/txt/msg00550.txt.bz2 > Now, there is a little detail missing - how GDB relocate the dummy frame > object that contains those saved registers. The problem is that GDB > can't just take the most recent one as, due to long jumps and the like, > it can be wrong. I can't comment on the internal mechanism, but I know that as a user of gdb, if something happens during a hand function call to marker2() like gdb hitting another breakpoint or me hitting ^C, then gdb starts acting a little drunk at that point. So I bet that explicit save/restore of these frames would help. Michael C