From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89501 invoked by alias); 14 Jun 2016 11:40:22 -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 89477 invoked by uid 89); 14 Jun 2016 11:40:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2134 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 14 Jun 2016 11:40:20 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 31C75821C7; Tue, 14 Jun 2016 11:40:19 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5EBeH0X001390; Tue, 14 Jun 2016 07:40:18 -0400 Subject: Re: [PATCH 04/12] Delete reinsert breakpoints from forked child To: Yao Qi References: <1464859846-15619-1-git-send-email-yao.qi@linaro.org> <1464859846-15619-5-git-send-email-yao.qi@linaro.org> <86twgxt4hg.fsf@gmail.com> <86porkt3yy.fsf@gmail.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Tue, 14 Jun 2016 11:40:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <86porkt3yy.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-06/txt/msg00250.txt.bz2 On 06/14/2016 12:16 PM, Yao Qi wrote: >> > >>> >> I think >>> >> they've already covered by gdb.base/step-over-syscall.exp. >> > >> > In that case, shouldn't we be extending that test instead? > OK, I extend step-over-syscall.exp by setting different > combinations of follow-fork and detach-on-fork modes, and it still can > trigger GDBserver internal errors. How about the patch below? Fine with me. One suggestion below. > + foreach_with_prefix detach-on-fork {"on" "off"} { > + foreach_with_prefix follow-fork {"parent" "child"} { > + foreach syscall { "fork" "vfork" "clone" } { > + > + if { $syscall != "vfork" > + || ${follow-fork} != "parent" > + || ${detach-on-fork} != "off" } { > + # Both vforked child process and parent process are > + # under GDB's control, but GDB follows the parent > + # process only, which can't be run until vforked child > + # finishes. Skip the test in this scenario. > + break_cond_on_syscall $syscall ${follow-fork} ${detach-on-fork} > + } I'd suggest reversing the condition logic, making it match the comment, like this: if { $syscall == "vfork" && ${follow-fork} == "parent" && ${detach-on-fork} == "off" } { # Both vforked child process and parent process are # under GDB's control, but GDB follows the parent # process only, which can't be run until vforked child # finishes. Skip the test in this scenario. continue } break_cond_on_syscall $syscall ${follow-fork} ${detach-on-fork} This way makes it easier to add more "skip" conditions in the future too. E.g., if { $syscall == "vfork" && ${follow-fork} == "parent" && ${detach-on-fork} == "off" } { # Both vforked child process and parent process are # under GDB's control, but GDB follows the parent # process only, which can't be run until vforked child # finishes. Skip the test in this scenario. continue } + if { $syscall == "whatnot" + && ${follow-fork} == "parent"} { + # For whatever reason, this shouldn't be tested either. + continue + } break_cond_on_syscall $syscall ${follow-fork} ${detach-on-fork} > + } > + } > + } > } Thanks, Pedro Alves