From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6216 invoked by alias); 2 Apr 2004 23:57:25 -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 6209 invoked from network); 2 Apr 2004 23:57:23 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sources.redhat.com with SMTP; 2 Apr 2004 23:57:23 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 9499147D62; Fri, 2 Apr 2004 15:57:22 -0800 (PST) Date: Fri, 02 Apr 2004 23:57:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: Ulrich Weigand , gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] Use frame_type for sigtramp test in infrun.c Message-ID: <20040402235722.GE871@gnat.com> References: <200403292338.BAA16799@faui1d.informatik.uni-erlangen.de> <406DD226.1080104@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <406DD226.1080104@gnu.org> User-Agent: Mutt/1.4i X-SW-Source: 2004-04/txt/msg00087.txt.bz2 > Joel, from memory you had a change to: > > if (((stop_pc == ecs->stop_func_start /* Quick test */ > || in_prologue (stop_pc, ecs->stop_func_start)) > && !IN_SOLIB_RETURN_TRAMPOLINE (stop_pc, ecs->stop_func_name)) > || IN_SOLIB_CALL_TRAMPOLINE (stop_pc, ecs->stop_func_name) > || ecs->stop_func_name == 0) > { > /* It's a subroutine call. */ > handle_step_into_function (ecs); > return; > } > > pending? If we do pull the sigtramp code I think it would be prudent to > first have that committed - Joel's change greatly clarifies the logic. Yes. Something that would isolate this code to the platforms who haven't been framified yet (are there still any?). But the problem is that I got some regressions mostly on HP/UX, but also one on Tru64. The testsuite results were clean on sparc-solaris and x86-linux. The problem was that it was difficult for me to investigate the problems on HP/UX given the current status. So I started looking at the current failures on HP/UX to see if I could improve them a bit. I should probably redo some testing and see where we stand. Yeah, let me do that. -- Joel