From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15442 invoked by alias); 2 Nov 2003 04:17:54 -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 15435 invoked from network); 2 Nov 2003 04:17:53 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 2 Nov 2003 04:17:53 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AG9gW-0007Qv-A1; Sat, 01 Nov 2003 23:17:52 -0500 Date: Sun, 02 Nov 2003 04:17:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [commit] Don't call deprecated_inside_entry_file from ...id_unwind() Message-ID: <20031102041751.GA17602@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <3FA2F789.5000306@redhat.com> <20031101004443.GB11987@nevyn.them.org> <3FA3141C.7040900@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FA3141C.7040900@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-11/txt/msg00014.txt.bz2 On Fri, Oct 31, 2003 at 09:02:04PM -0500, Andrew Cagney wrote: > > >Are you certain that none of those other architectures needed the hack > >anyway? > > To sound like a scratched record, until there is hard evidence that this > test is needed it should _not_ be enabled. So far the only evidence is > that it is anything but needed: > > /* NOTE: vinschen/2003-04-01: Disabled. It turns out that the call > to deprecated_inside_entry_file destroys a meaningful backtrace > under some conditions. E. g. the backtrace tests in the > asm-source testcase are broken for some targets. In this test > the functions are all implemented as part of one file and the > testcase is not necessarily linked with a start file (depending > on the target). What happens is, that the first frame is printed > normaly and following frames are treated as being inside the > enttry file then. This way, only the #0 frame is printed in the > backtrace output. */ > > Also, as I noted: I was confusing inside_entry_file and inside_entry_func again. My apologies. I'm still pretty confident that the test was necessary when I added it to the ARM target, i.e. something broke without it - I remember not copying and pasting it, but actually going looking for it. I'll retest when I get the time. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer