From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2306 invoked by alias); 7 Apr 2008 13:29:28 -0000 Received: (qmail 2293 invoked by uid 22791); 7 Apr 2008 13:29:27 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 07 Apr 2008 13:29:05 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m37DT2Ds029010; Mon, 7 Apr 2008 09:29:02 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m37DT1va024881; Mon, 7 Apr 2008 09:29:01 -0400 Received: from localhost.localdomain (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m37DT1wE006934; Mon, 7 Apr 2008 09:29:01 -0400 Message-ID: <47FA219C.9010807@redhat.com> Date: Mon, 07 Apr 2008 13:34:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Mark Wielaard CC: frysk Subject: Re: [patch] Signal frame tests and fix References: <1207568559.3504.33.camel@localhost.localdomain> In-Reply-To: <1207568559.3504.33.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2008-q2/txt/msg00032.txt.bz2 Mark, Sounds more than worthy of a news entry! Andrew Mark Wielaard wrote: > Hi, > > This adds a couple of tests for unwinding when signals are involved. We > would like to unwind as if at the interrupted place in the program the > unwind stack frames continue from the signal handler (and anything > called from the signal handler). The first test > (testFirstFrameInSignalHandler) exposed an bug in the ptrace handling of > single stepping. We detect when the stepping flag isn't set in a couple > of special cases, but then forgot to inform the Instruction observer, > which made us miss the first instruction and frame of the signal > handler. The fix is easy and included. The second test > (testReturnFrameAfterSignalHandler) works on x86_64, but seems to expose > a kernel bug on x86. Filed as bug #6044 and created a ptrace-testsuite > reproducer so hopefully Roland can help me out there. The last test > finally shows the issue why I started this work > (testStepSignalCallAllFrames). It steps through the whole signal handler > and checks the call frame is correct on every step. It works on x86_64 > which had debug (eh) frame info everywhere, but fails on x86 where we > have to detect the signal trampoline code by hand to produce a good > unwind (similar to how we handle unwinding from PLT entries). > > frysk-core/frysk/pkglibdir/ChangeLog > 2008-04-07 Mark Wielaard > > * funit-loop-signal.c: New test. > > frysk-core/frysk/proc/live/ChangeLog > 2008-04-07 Mark Wielaard > > * LinuxPtraceTaskState.java (Stepping.handleTrappedEvent): > Explicitly notify Instruction observers in special > "no step bit set" cases. > > frysk-core/frysk/stack/ChangeLog > 2008-04-07 Mark Wielaard > > * TestSignalStepFrame.java: New tests. > > All tests PASS on x86_64. The last two are marked unresolved on x86. > Working on that. And adding some more tests (for using sigaltstack and > nested signals). > > Committed and pushed. No Regressions on x86 and x86_64 (fedora 8). > > Mark >