From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13580 invoked by alias); 19 Feb 2003 21:21:08 -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 13573 invoked from network); 19 Feb 2003 21:21:08 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 19 Feb 2003 21:21:08 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 1CFC42E96; Wed, 19 Feb 2003 16:25:53 -0500 (EST) Message-ID: <3E53F660.6090809@redhat.com> Date: Wed, 19 Feb 2003 21:21:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.0.2) Gecko/20030217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: GDB Patches Subject: Re: [patch/rfc] Add a sentinel frame References: <20030219140441.GA20537@nevyn.them.org> <3E53B61C.2050807@redhat.com> <20030219165623.GA7961@nevyn.them.org> <3E53BBCB.2010003@redhat.com> <20030219171700.GA8736@nevyn.them.org> <3E53C416.30809@redhat.com> <20030219175654.GA10010@nevyn.them.org> <3E53CFB8.8070201@redhat.com> <20030219185202.GA11371@nevyn.them.org> <3E53E8B8.10203@redhat.com> <20030219203937.GA14890@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00443.txt.bz2 > Oh, but you're misunderstanding. There's more than one frame in there. > The call stack in glibc looks like: > _start > calls __libc_start_main > calls main Nope, that assumes glibc. Remember, i debugged this using the d10v. > _start is written in assembly; it generally doesn't have a frame worth > talking about. Even if we want to show __libc_start_main, we can't > safely backtrace into _start. That's what the inside_entry_file > (frame_pc_unwind (fi)) is for. Why not? If someone wants to do that, why should we stand in their way :-) > Now, if we want to do this anyway, that's different. But it's a > change, not a redundancy. The entire get_prev_frame is change. It should only affect targets converted to the new code though (if it wasn't for this sentinel edge condition). > The missing test I mentioned above inside_entry_func, not > inside_entry_file. Where'd that go? Left until something that does need it surfaces. >> As things progress, and more targets switch to the new code, the tests >> in get_prev_frame will most likely evolve. However, I don't know that >> we want to be adding tests without hard evidence that they are needed :-/ >> >> Having said that, sanity checks that the frame didn't go backwards: >> !frame_id_inner (frame_id, get_frame_id (next_frame))? > > > Yes. > > >> and that they changed: >> !frame_id_eq (frame_id, get_frame_id (next_frame))? > > > Can we do that? Hmm, we probably can. A frame ID has a PC in it and a > stack pointer, and if neither has changed we're probably stuck in a > rut. legacy_get_prev_frame() contains exactly that test. Andrew