From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25325 invoked by alias); 24 Sep 2004 00:16:48 -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 25256 invoked from network); 24 Sep 2004 00:16:43 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sourceware.org with SMTP; 24 Sep 2004 00:16:43 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 195AC47D95; Thu, 23 Sep 2004 17:16:43 -0700 (PDT) Date: Fri, 24 Sep 2004 00:16:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: [mips] Getting rid of heuristic proc_desc Message-ID: <20040924001643.GK968@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-SW-Source: 2004-09/txt/msg00389.txt.bz2 Hello Andrew, Looking at the mips code, I think the goal is to get rid entirely of heuristic procedure descriptors. Right now, they are used as an intermediate frame information recipient on our way to create frame caches, which is OK in non heuristic cases, but unnecessary in the heuristic ones. And I'd like to keep the usage of non-heuristic procedure descriptors as locally contained as possible. Looking a bit closer, though, I found that we are not quite there yet. There is a case where we to create proc_descs without needing a frame cache (to skip the prologue, presumably). And this is a bit problematic, because in this case we can't replace the proc desc by the frame cache, since we can not necessarily create the frame cache. The only place I see where heuristic_proc_desc() is called and where it could cause a bit of trouble getting rid of is in after_prologue(). I'll let you look at the code, but this check basically is the only reason why we try finding the non-heuristic proc_desc and/or the heuristic one: if (proc_desc) { /* If function is frameless, then we need to do it the hard way. I strongly suspect that frameless always means prologueless... */ if (PROC_FRAME_REG (proc_desc) == MIPS_SP_REGNUM && PROC_FRAME_OFFSET (proc_desc) == 0) return 0; } On the one hand, all we appear to be using from the proc_desc is the PROC_FRAME_REG and PROC_FRAME_OFFSET. So I am thinking we could in the heuristic case the two values returned by mips32/mips16__heuristic_proc_desc, and somehow get these values back to after_prologue. So we would no longer need the proc_desc, just these two values. On the other hand, when I look a bit deeper, I find that mips_skip_prologue is only used in mips_skip_prologue(). static CORE_ADDR mips_skip_prologue (CORE_ADDR pc) { /* See if we can determine the end of the prologue via the symbol table. If so, then return either PC, or the PC after the prologue, whichever is greater. */ CORE_ADDR post_prologue_pc = after_prologue (pc); if (post_prologue_pc != 0) return max (pc, post_prologue_pc); /* Can't determine prologue from the symbol table, need to examine instructions. */ if (pc_is_mips16 (pc)) return mips16_skip_prologue (pc); else return mips32_skip_prologue (pc); } I was thinking that it should be possible to merge mips32_skip_prologue inside mips32_heuristic_proc_desc (what a bad name for this function now). But I am wondering if this wouldn't make heuristic_proc_desc too complicated? I am thinking also that if we were to inline after_prologue inside mips_skip_prologue, then maybe this would allow us to make some simplifications... And maybe all three ideas are orthogonal, and should all be applied? Hmm.... Not sure which way I should go. Any hunch? -- Joel