From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73376 invoked by alias); 26 Nov 2015 10:34:24 -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 73356 invoked by uid 89); 26 Nov 2015 10:34:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 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; Thu, 26 Nov 2015 10:34:22 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 8CE458E373; Thu, 26 Nov 2015 10:34:21 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAQAYIR6003294; Thu, 26 Nov 2015 05:34:19 -0500 Message-ID: <5656E02A.3090207@redhat.com> Date: Thu, 26 Nov 2015 10:34:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Josh Stone , gdb-patches@sourceware.org CC: philippe.waroquiers@skynet.be, sergiodj@redhat.com, eliz@gnu.org, xdje42@gmail.com Subject: Re: [PATCH v2 1/2] gdbserver: Set Linux ptrace options ASAP References: <1446169946-28117-1-git-send-email-jistone@redhat.com> <1448506425-24691-1-git-send-email-jistone@redhat.com> In-Reply-To: <1448506425-24691-1-git-send-email-jistone@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-11/txt/msg00542.txt.bz2 On 11/26/2015 02:53 AM, Josh Stone wrote: > The ptrace options should be set as soon as we know a thread is stopped, > so no events can be missed. There's an arch-setup early return that was > effectively delaying this update before, and I found for instance that > the first syscall event wouldn't be properly reported with TRACESYSGOOD. > It's now more similar to the way that gdb/linux-nat.c handles it. Hmm, I'm confused on how this resulted in the first syscall being misssed. That early return happens when we're not executing the real inferior yet -- the process is still running the "gdbserver --wrapper WRAPPER" binary. It's pedantically good, though not crucial, to set PTRACE_O_TRACEEXEC early for that scenario, to get a real PTRACE_EVENT_EXEC event instead of a bare SIGTRAP when the exec wrapper (or in the future, the shell, when we start inferiors with the shell, like gdb does, for arg expansion and globbing) actually execs. If the shell/wrapper forks, enabling fork events while still executing the wrapper/shell breaks startup -- server.c:start_inferior. The gdb version (fork-child.c:startup_inferior) does handle TARGET_WAITKIND_FORKED, but AFAICS forgets detaching/resuming the child... We _must_ not catch syscall events while running the exec wrapper (or the shell), otherwise server.c:start_inferior would get confused for seeing unexpected syscall stops. If the backend treats syscall catchpoints, it's OK, since gdb won't insert catchpoints in the process until after vRun returns, indicating the process is stopped at the entry point. IIRC, gdb actually does NOT handle catchpoint locations per-inferior today, but as long as the backend side thinks of catchpoints per-inferior, we can fix the GDB side. So all in all, I'm not sure this actually buys us anything other than need to fix the wrapper/shell-forks case. > > gdb/gdbserver/ChangeLog: > > 2015-11-25 Josh Stone > > * linux-low.c (linux_low_filter_event): Set ptrace options as soon as > each thread is stopped, even before arch-specific setup. Thanks, Pedro Alves