From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15568 invoked by alias); 25 Mar 2004 04:03:24 -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 15561 invoked from network); 25 Mar 2004 04:03:22 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 25 Mar 2004 04:03:22 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B6M5S-0003Om-AD; Wed, 24 Mar 2004 23:03:22 -0500 Date: Thu, 25 Mar 2004 06:26:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Cc: cagney@gnu.org Subject: [mips] When to use a proc_desc Message-ID: <20040325040322.GA12885@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com, cagney@gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00249.txt.bz2 find_proc_desc has this bit of dead code in it - next_frame is never NULL: /* 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. */ if (next_frame == NULL) { This used to work (and was necessary). Nowadays, the equivalent check would be: frame_relative_level (next_frame) < 0 and if you really wanted to capture the intent of the original check, you'd also need: get_frame_type (next_frame) != NORMAL_FRAME Obviously, as we just discussed with my other patch, the point is to avoid this grubbing up the chain. But proc_desc's have no way to verify that things have already been saved, so we just lose out right now. This corresponds to several failures in the testsuite on MIPS GNU/Linux (along with a couple of related problems, which have less objectionable solutions). Basically, if the current frame has not been running long enough to save all its registers, the proc_desc can lead us easily down an unwinding rathole; it's inherently unreliable because it has no prologue end marker. How can we handle this? Eventually I want to turn on DWARF-2 unwinding support in GDB, at which point we may not want to support GAS's .pdr at all (even if we have to continue supporting it for some other MIPS target). But in the meantime I'd like to fix the regressions in it. BTW, even in_prologue is not a good enough check, with optimized code. I have several testcases where registers are not saved until "after" the prologue. But the checks in mips32_decode_reg_save are [generally] good enough for this. So that's a recent improvement over the previous code. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer