From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19990 invoked by alias); 29 Mar 2004 23:38:39 -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 19980 invoked from network); 29 Mar 2004 23:38:36 -0000 Received: from unknown (HELO faui10.informatik.uni-erlangen.de) (131.188.31.10) by sources.redhat.com with SMTP; 29 Mar 2004 23:38:36 -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 BAA09177; Tue, 30 Mar 2004 01:38:35 +0200 (CEST) From: Ulrich Weigand Received: (from weigand@localhost) by faui1d.informatik.uni-erlangen.de (8.9.3p3/8.1.6-FAU) id BAA16799; Tue, 30 Mar 2004 01:38:35 +0200 (CEST) Message-Id: <200403292338.BAA16799@faui1d.informatik.uni-erlangen.de> Subject: Re: [patch/rfc] Use frame_type for sigtramp test in infrun.c To: cagney@gnu.org Date: Mon, 29 Mar 2004 23:38:00 -0000 Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00739.txt.bz2 Andrew Cagney wrote: > * infrun.c (handle_inferior_event): For non legacy frames, use the > frame ID and frame type to identify a signal trampoline. Update > comments. This breaks signals.exp on s390 again. What now happens is the following: - we are in main and do 'next'; step_frame_id is set to the current frame - gdb starts single-stepping - in the meantime, a signal has arrived and the kernel invokes the handler Note that the kernel directly jumps to the handler, and sets up the return address to point to the signal return trampoline. - gdb single-steps and stops on the first instruction of the handler at this point, the call-chain is handler main - gdb thinks it has stepped into a subroutine, and does handle_step_into_function, which calls keep_going - keep_going saves the current pc (i.e. start of handler) into prev_pc - we run until the return from handler, i.e. we stop on the first (and only) instruction of the signal trampoline - now the 'if' you changed hits because we are in fact in a signal trampoline frame. - within the if, there's a second if that tries to distiguish between stepping into a trampoline before the signal handler from one after the signal handler. This is attempted via if (frame_id_inner (current_frame, step_frame_id)) - unfortunately, step_frame_id is still the frame of 'main', and thus the current (i.e. trampoline) frame *is* 'inner', even though we actually have a trampoline after, not before the handler. - gdb now does sr_sal.line = 0; sr_sal.pc = prev_pc; /* We could probably be setting the frame to step_frame_id; I don't think anyone thought to try it. */ check_for_old_step_resume_breakpoint (); step_resume_breakpoint = set_momentary_breakpoint (sr_sal, null_frame_id, bp_step_resume); However, prev_pc was set to first instruction of handler above - since we never again enter the handler, the breakpoint is never hit and we run until the end of main I'm not sure what the correct way to fix this issue would be. However, simply removing the whole 'if' block makes signals.exp pass on s390. This is because both the handler and the signal return trampoline are now simply treated as calls into subroutines, and both are skipped with step_over_function, so that everything works just as expected. Why is this if needed in the first place? Isn't this just to work around frame problems that caused step_over_function to not handle signal handlers correctly? I.e. if we have new-style frames that work properly, can't we just skip that whole if? Bye, Ulrich -- Dr. Ulrich Weigand weigand@informatik.uni-erlangen.de