From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121797 invoked by alias); 16 Mar 2016 10:47:17 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 121705 invoked by uid 89); 16 Mar 2016 10:47:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=3300, stepped, $pc, retq X-HELO: mail-pf0-f177.google.com Received: from mail-pf0-f177.google.com (HELO mail-pf0-f177.google.com) (209.85.192.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 16 Mar 2016 10:47:07 +0000 Received: by mail-pf0-f177.google.com with SMTP id n5so70506232pfn.2 for ; Wed, 16 Mar 2016 03:47:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=k6MAHYWSqje4aJfG+pvcghuMD8FU0Jjy2ZOczOy0OsA=; b=YSohAtfHSDZ3RRYQYy5A2+VSpSVy3A1XPR2o1HaBXMTNUf5istHAbToCQrWuepG6UF 57/76INZYOepVUE50Gos5t7uB2ELBa55n/GhKBoDcisn3xNkCK8R8mzCVYUJ+pVGMK7f DKXGJrmCHwJEawDP9zq53Y6TgFSDgyoVRs1wSgxEVLQiWX+l7xzGamFyvvTkxwg99sUW qttjzYRImU327wtRMTSNIlnsT7WD60XCPEqDW8uMoWFRx3t5/nw5UqX4bWFQJwujVgvV Z1LI2tRkApTE6NG8/ajHtO305O4u6cG/YQW5y3FVuBKztwoio3lh3VNks9V5z5dgx9V0 G/RQ== X-Gm-Message-State: AD7BkJIZZKQKwVVgv0QEUSku3VzSCaIjZZb3dkEZVLL6qkZ2TCVd2ZmHCeFM01Dal7oyCA== X-Received: by 10.66.190.168 with SMTP id gr8mr4715120pac.23.1458125225600; Wed, 16 Mar 2016 03:47:05 -0700 (PDT) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id r88sm4624979pfi.9.2016.03.16.03.47.03 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 16 Mar 2016 03:47:04 -0700 (PDT) From: Yao Qi To: Pedro Alves Cc: Yao Qi , gdb-patches@sourceware.org Subject: Re: [PATCH 3/8] Deliver signal in hardware single step References: <1457088276-1170-1-git-send-email-yao.qi@linaro.org> <1457088276-1170-4-git-send-email-yao.qi@linaro.org> <56E2A685.2080602@redhat.com> <56E2A753.9060805@redhat.com> <56E2AE04.7030306@redhat.com> Date: Wed, 16 Mar 2016 10:47:00 -0000 In-Reply-To: <56E2AE04.7030306@redhat.com> (Pedro Alves's message of "Fri, 11 Mar 2016 11:37:40 +0000") Message-ID: <86io0mya1n.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00252.txt.bz2 Pedro Alves writes: Hi Pedro, > - If there's a signal handler installed, we'll stop at its entry, > but we haven't stepped over the original breakpoint yet. If we > were already stopped at the entry of the signal handler, and it > nested, we'll find the program stopped at the same PC it had > started at. But we won't know whether the step-over finished > successfully (could be a "jmp $pc" instruction), or if instead we're > in a new handler invocation, and thus this is a new, > separate breakpoint hit. GDBserver doesn't have to tell the program stopped at the same PC it had started at when step over is finished. When step over, GDBserver uninsert breakpoint, resumes the lwp, and wait the next event from the lwp. Once the event from the lwp arrives, GDBserver reinsert breakpoint and thinks step over is finished. That is all ... > > A signal handler that segfaults in the first instruction > would be the easiest way to reproduce this that I can think of. > (If it's crashing, you'd expect the user might try putting a > breakpoint there.) I write a case like this, set the conditional breakpoint on the first instruction of handler, and looks breakpoint condition in target side still works properly. (gdb) disassemble handler Dump of assembler code for function handler: 0x0000000000400586 <+0>: movb $0x0,0x0 0x000000000040058e <+8>: retq (gdb) p/x $rsp $1 =3D 0x7fffffffde00 (gdb) b *handler if $rsp < 0x7fffffffde00 - 3300 the condition like this can guarantee that the condition will be true after several recursions. > > Now, if after stepping into the handler, we immediately reinsert the=20 > breakpoint and continue, we'll retrap it, it ends up OK. breakpoint is reinserted after stepping into the handler, because GDBserver thinks step over is finished, as I said above. > But if we immediately instead start a new step-over for the same=20 > breakpoint address, we will miss the new hit, and nest a new handler, > on and on. This won't happen. After hardware single step with signal delivered, the program stops at the entry of handler, and GDBserver gets an event. Then, GDBserver thinks step over is finished, and then proceed all lwps. However, the thread still stopped at the breakpoint (of different stack frames), so it needs step over again. The loop like this will go on until the breakpoint condition is true, need_step_over_p decides to resume rather than step over. The program will hit the breakpoint, and GDBserver reports the event back to GDB. Note in my experiment with the test case above, I don't let GDBserver treat SIGSEGV as SIGTRAP, otherwise SIGSEGV will be reported back to GDB. --=20 Yao (=E9=BD=90=E5=B0=A7)