From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 724 invoked by alias); 26 Nov 2004 17:26:17 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 691 invoked from network); 26 Nov 2004 17:26:11 -0000 Received: from unknown (HELO mtagate1.de.ibm.com) (195.212.29.150) by sourceware.org with SMTP; 26 Nov 2004 17:26:11 -0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id iAQHQAug075052 for ; Fri, 26 Nov 2004 17:26:10 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAQHQ6tk130548 for ; Fri, 26 Nov 2004 18:26:06 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id iAQHQ9kj017403 for ; Fri, 26 Nov 2004 18:26:09 +0100 Received: from d12ml068.megacenter.de.ibm.com (d12ml068.megacenter.de.ibm.com [9.149.164.163]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id iAQHQ9u8017398 for ; Fri, 26 Nov 2004 18:26:09 +0100 Subject: PTRACE_SINGLESTEP into signal handler To: gdb@sources.redhat.com Message-ID: From: Ulrich Weigand Date: Sat, 27 Nov 2004 23:28:00 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-SW-Source: 2004-11/txt/msg00246.txt.bz2 Hello, I'm seeing failures in the sigstep.exp test case on s390: FAIL: gdb.base/sigstep.exp: step on breakpoint, to handler entry; performing step FAIL: gdb.base/sigstep.exp: next on breakpoint, to handler entry; performing next FAIL: gdb.base/sigstep.exp: continue on breakpoint, to handler entry; performing continue The reason for this appears to be that they set a breakpoint on the very first instruction of a signal handler that is being stepped into via PTRACE_SINGLESTEP. For some reason, while this is done, the breakpoints are not actually inserted. When the debugger next gets control, the first instruction of the handler was already executed. Thus, while it now does insert the breakpoint instructions, it is too late ... Does gdb assume PTRACE_SINGLESTEP into a handle returns *before* the first instruction of the handler was executed? We could change the kernel to do that, and this fixes the test case failures, but I'm not sure if this is the right thing to do -- the ptrace documentation says "arranges for the child to be stopped after execution of a single instruction", which would appear to indicate the current behaviour is correct. How does this work on other platforms? Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand Linux for S/390 Design & Development IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen Phone: +49-7031/16-3727 --- Email: Ulrich.Weigand@de.ibm.com