From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13130 invoked by alias); 31 Aug 2004 23:44:33 -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 13108 invoked from network); 31 Aug 2004 23:44:31 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sourceware.org with SMTP; 31 Aug 2004 23:44:31 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 3288647D91; Tue, 31 Aug 2004 16:44:30 -0700 (PDT) Date: Tue, 31 Aug 2004 23:44:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA/RFC] fix problems with unwinder on mips-irix Message-ID: <20040831234430.GX969@gnat.com> References: <20040723011059.GI20596@gnat.com> <410994BD.5040506@gnu.org> <20040803044358.GA18163@gnat.com> <411039F3.1020102@gnu.org> <20040830181829.GC969@gnat.com> <41338063.7020500@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41338063.7020500@gnu.org> User-Agent: Mutt/1.4i X-SW-Source: 2004-08/txt/msg00792.txt.bz2 Andrew, > Yes, sometimes inlineing doesn't help, here it does. There's really no > value in trying to preserve this code so be brutal. Thanks a lot for the detailed message. Really appreciated. I'm trying to find my way through all this. Let's first look at inlining find_proc_desc. I'll work on the rest as soon as I have this one figured out. Reading your last commit to this file, I discovered that you added frame sniffers, so, if I understand correctly, we can now more or less predict the circumstances under which find_proc_desc should be called (heuristic vs non-heuristic). Is that right? find_proc_desc is called by 4 routines: 1. mips_mdebug_frame_cache /* Get the mdebug proc descriptor. */ proc_desc = find_proc_desc (frame_pc_unwind (next_frame), next_frame, 1); In that case, I think this call can be replaced by a call to non_heuristic_proc_desc? How about the handling this case: /* IF this is the topmost frame AND * (this proc does not have debugging information OR * the PC is in the procedure prologue) * THEN create a "heuristic" proc_desc (by analyzing * the actual code) to replace the "official" proc_desc. */ 2. mips_insn16_frame_cache 3. mips_insn32_frame_cache In these two cases, the call to find_proc_desc can be reduced to the case where the heuristics have to be used. You said it can be inline using something like this: if (startaddr == 0) startaddr = heuristic_proc_start (pc); proc_desc = heuristic_proc_desc (startaddr, pc, next_frame, cur_frame); I see that linked_proc_desc_table is never used, which explains why we can get rid of: /* Is linked_proc_desc_table really necessary? It only seems to be used by procedure call dummys. However, the procedures being called ought to have their own proc_descs, and even if they don't, heuristic_proc_desc knows how to create them! */ struct linked_proc_info *link; for (link = linked_proc_desc_table; link; link = link->next) if (PROC_LOW_ADDR (&link->info) <= pc && PROC_HIGH_ADDR (&link->info) > pc) return &link->info; 4. after_prologue So far so good. But there there is the case of after_prologue: /* Pass cur_frame == 0 to find_proc_desc. We should not attempt to read the stack pointer from the current machine state, because the current machine state has nothing to do with the information we need from the proc_desc; and the process may or may not exist right now. */ if (!proc_desc) proc_desc = find_proc_desc (pc, NULL, 0); The only place where this function is called is in mips_skip_prologue: CORE_ADDR post_prologue_pc = after_prologue (pc, NULL); So arguably we could remove this extra parameter from after_prologue. Should we do this? Back to find_proc_desc, I suppose the above code should be replaced by something like this: if (!proc_desc) proc_desc = non_heuristic_proc_desc (pc, &startaddr); if (!proc_desc) proc_desc = heuristic_proc_desc (pc); Would that be right? Same question as in point 1 above, actually. Thanks, -- Joel