From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1836 invoked by alias); 31 Mar 2003 20:12: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 1829 invoked from network); 31 Mar 2003 20:12:46 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 31 Mar 2003 20:12:46 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id B86DC2B29; Mon, 31 Mar 2003 15:12:45 -0500 (EST) Message-ID: <3E88A13D.6010405@redhat.com> Date: Mon, 31 Mar 2003 20:12: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: Jason Molenda Cc: gdb-patches@sources.redhat.com Subject: Re: Adding -file-list-exec-source-file command to GDB/MI References: <20030320224454.GA14096@white> <20030321015532.A54903@molenda.com> <20030321131614.GA14884@white> <3E846994.3040708@redhat.com> <20030330040652.GA8455@white> <3E87C26B.5060102@redhat.com> <20030331001815.A647@molenda.com> <3E885148.6050401@redhat.com> <20030331092203.A40264@molenda.com> <3E888E73.8050601@redhat.com> <20030331112537.A73741@molenda.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00615.txt.bz2 > Ah, now I see. You didn't mean "That doesn't work", you meant "That > doesn't work generally". "Generally" isn't the issue. GDB needs changes that work. As you note with #2 > #1 doesn't apply to us at Apple. #2 is a real problem - although > the failure mode is that the UI re-fetches the stack, so it's not > too traumatic. And because it only needs to re-fetch the 0th frame, > it is fast. And you'll have the same problem with varobj's being > deleted when your FP moves IIRC. even for Apple, this doesn't work. Per my original comment, and many previous posts, MI (varobj) needs to switch to frame IDs. > As for #3, I don't understand why the PC won't remain constant for > a frame other than the 0th, but you're familiar with far more > architectures than me. Obviously the currently executing frame > will have a changing PC, but the frames higher up on the stack > should stay constant unless they've executed some more. The function address is needed when trying to correctly re-identify a frame that has executed. Andrew