From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82859 invoked by alias); 8 Dec 2015 13:31:34 -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 82842 invoked by uid 89); 8 Dec 2015 13:31:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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; Tue, 08 Dec 2015 13:31:29 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 23F748C1A9; Tue, 8 Dec 2015 13:31:28 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB8DVO2x020535; Tue, 8 Dec 2015 08:31:25 -0500 Message-ID: <5666DBAC.5030401@redhat.com> Date: Tue, 08 Dec 2015 13:31: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 v3 2/2] Implement 'catch syscall' for gdbserver References: <1448506425-24691-1-git-send-email-jistone@redhat.com> <1449196006-13759-1-git-send-email-jistone@redhat.com> <1449196006-13759-2-git-send-email-jistone@redhat.com> <5661929E.7020406@redhat.com> <566248F2.5020908@redhat.com> In-Reply-To: <566248F2.5020908@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-12/txt/msg00157.txt.bz2 On 12/05/2015 02:16 AM, Josh Stone wrote: > On a total tangent, is it ever possible that GDB/GDBserver might try to > read and modify registers from a PTRACE_EVENT stop? Do "catch fork", and you'll be given a prompt right inside a PTRACE_EVENT_FORK, where you can try to poke at registers at will. > If so, you should > beware that registers may actually be in flux. I ran into this with > Dyninst, which I fixed here[1] though I can't find the discussion now. > Ouch. > The gist was that in a PTRACE_EVENT, the kernel may not have written the > return register yet. Dyninst wanted to save registers, resume in a bit > of instrumentation code, then restore registers and resume the normal > program. So the saved registers got an intermediate RAX, and when it > resumed into instrumentation the kernel finally wrote the good RAX > return value to complete the syscall (which the instrumentation > ignored). Then when dyninst restored registers the bad RAX was written > back, and thus the normal program code didn't get the correct value for > its fork return. My solution was to step out of the event with > PTRACE_SYSCALL before doing anything else. > > [1] > http://git.dyninst.org/?p=dyninst.git;a=commit;h=b89ea1d19677fa0dd9c605ef492c5f6dabf15752 Just to be clear, doesn't $orig_rax help here? Are you saving/restoring that? Otherwise, it sounds like trying to run an inferior function call [(gdb) p foo_func()] when the program is stopped for "catch fork" may misbehave too. Thanks, Pedro Alves