From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20139 invoked by alias); 11 Mar 2004 17:11:03 -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 20130 invoked from network); 11 Mar 2004 17:11:02 -0000 Received: from unknown (HELO faui10.informatik.uni-erlangen.de) (131.188.31.10) by sources.redhat.com with SMTP; 11 Mar 2004 17:11:02 -0000 Received: from faui1d.informatik.uni-erlangen.de (faui1d [131.188.31.34]) by faui10.informatik.uni-erlangen.de (8.9.3p3/8.1.9-FAU) with ESMTP id SAA26392; Thu, 11 Mar 2004 18:11:00 +0100 (CET) From: Ulrich Weigand Received: (from weigand@localhost) by faui1d.informatik.uni-erlangen.de (8.9.3p3/8.1.6-FAU) id SAA06213; Thu, 11 Mar 2004 18:11:00 +0100 (CET) Message-ID: <200403111711.SAA06213@faui1d.informatik.uni-erlangen.de> Subject: Re: [PATCH] Fix signals.exp test case on S/390 To: cagney@gnu.org (Andrew Cagney) Date: Thu, 11 Mar 2004 17:11:00 -0000 Cc: weigand@i1.informatik.uni-erlangen.de (Ulrich Weigand), gdb-patches@sources.redhat.com In-Reply-To: <40508EDA.1080502@gnu.org> from "Andrew Cagney" at Mar 11, 2004 11:07:54 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03.o/txt/msg00270.txt Message-ID: <20040311171100.vf3EyAkFiSzoWPBaSZWRPksMGSIioZSlYkz9WaRmdvA@z> Andrew Cagney wrote: > > It will run into the first if, and simply use step_frame_id, > > which is wrong in this case. That's why my patch add another > > condition to the first if, to make it not taken and actually > > use the (correct) get_prev_frame case. > > Where is step_frame_id pointing? To the function that was interrupted by the signal (i.e. the function where I entered 'next'). > Anyway, I think this code: > > if (frame_id_p (step_frame_id) > > && !IN_SOLIB_DYNSYM_RESOLVE_CODE (sr_sal.pc)) > > /* NOTE: cagney/2004-02-27: Use the global state's idea of the > > stepping frame ID. I suspect this is done as it is lighter > > weight than a call to get_prev_frame. */ > > sr_id = step_frame_id; > should simply be deleted. I wondered about it and you've just confirmed > my suspicions. With that code gone is half the problem solved? Yes, deleting this works just fine for me, in fact ... > That leaves the other problem, which is much harder :-( ... it even solves the other problem as well! The reason for this is that the whole problematic if that uses frame_id_inner becomes irrelevant: if (pc_in_sigtramp (stop_pc) && frame_id_inner (step_frame_id, frame_id_build (read_sp (), 0))) /* We stepped out of a signal handler, and into its calling trampoline. This is misdetected as a subroutine call, but stepping over the signal trampoline isn't such a bad idea. In order to do that, we have to ignore the value in step_frame_id, since that doesn't represent the frame that'll reach when we return from the signal trampoline. Otherwise we'll probably continue to the end of the program. */ step_frame_id = null_frame_id; step_over_function (ecs); With those lines in step_over_function deleted, step_over_function does not care about step_frame_id at all any more, and thus there is no need to fiddle with step_frame_id here ... > > Finally, the patch below reintroduces a pc_in_sigtramp > > gdbarch callback to s390-tdep.c; I had thought this would > > be no longer necessary when using the new frame code, but > > apparently there's still other users ... > > Yes, it shouldn't be needed. get_frame_type == SIGTRAMP_FRAME is > sufficient. work-in-progress. Actually, when deleting the lines in step_over_function, it turns out that I don't need pc_in_sigtramp any more ... Summing up: after completely reverting my patch, and simply deleting those lines, I get a gdb that passes signals.exp (and has no test suite regressions), and also handles stepping out of a signal handler correctly. Bye, Ulrich -- Dr. Ulrich Weigand weigand@informatik.uni-erlangen.de