From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89031 invoked by alias); 2 Dec 2015 14:01:55 -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 86392 invoked by uid 89); 2 Dec 2015 14:01:55 -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; Wed, 02 Dec 2015 14:01:44 +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 694B68F035; Wed, 2 Dec 2015 14:01:43 +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 tB2E1eDg003164; Wed, 2 Dec 2015 09:01:40 -0500 Message-ID: <565EF9C4.7070609@redhat.com> Date: Wed, 02 Dec 2015 14:01: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> <5656E02A.3090207@redhat.com> <565C9A73.9040707@redhat.com> <565E0060.3060104@redhat.com> In-Reply-To: <565E0060.3060104@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-12/txt/msg00034.txt.bz2 On 12/01/2015 08:17 PM, Josh Stone wrote: > OK, I think I've got it, and it's a real regression from 7.10 even for > other events like fork. I'm not using --wrapper, so I'm not sure of the > interaction there, but even gdbserver's simple fork+exec can show the > problem. Basically, on the very first stop we don't set flags yet, so > the first resume from there continues without the right flags. > > The sequence I was running into with syscalls goes like this: > > - start_inferior calls create_inferior to fork, then calls mywait > - the forked process calls ptrace(PTRACE_TRACEME), then execs > - linux_low_filter_event sees a raw SIGTRAP for the child after exec > - (we haven't set PTRACE_O_TRACEEXEC yet, so SIGTRAP is expected) > - arch setup is needed, so it hits the early return (new since 7.10) > ... thus child->must_set_ptrace_flags is not dealt with > - start_inferior calls target_arch_setup > - GDB sends QCatchSyscalls:1 > - linux_resume_one_lwp_throw calls ptrace(PTRACE_SYSCALL) > - but we still haven't set any flags, especially PTRACE_O_TRACESYSGOOD > - linux_low_filter_event sees a raw SIGTRAP for the first syscall entry > - now we finally deal with child->must_set_ptrace_flags > - linux_resume_one_lwp_throw calls ptrace(PTRACE_SYSCALL) > - linux_low_filter_event sees SYSCALL_SIGTRAP for the return > - entry/return logic is confused now, thinks this is an entry > - (but if there's any other event, entry/return will get back in sync) > > > But this problem isn't particular to my syscall patches. Consider this > simple forking program and use 'catch fork': > > #include > int main() { fork(); return 0; } > > Compiled normally, with dynamically-linked libc et al, you get: > - SIGTRAP after exec, ignores child->must_set_ptrace_flags. > - SIGTRAP for a swbreak, I guess some gdb setup, then it sets the > necessary flags, especially PTRACE_O_TRACEFORK. > - SIGTRAP for PTRACE_EVENT_FORK, hooray! > > But compiled statically: > - SIGTRAP after exec, ignores child->must_set_ptrace_flags. > - CLD_EXITED, flags were never set! > - if I add a breakpoint on main, flags will be set when that's reached, > and then we do get the PTRACE_EVENT_FORK after all. Ouch. Thanks, I'm clear now. It'd be super if one of these examples got converted to a test case. > > So, we need some point to get the right flags set before the program > starts running for real. If you don't like the way I moved the flags > before that arch-setup early return, then when should we do it? > > - Perhaps before the ptrace call in linux_resume_one_lwp_throw? Then if > any state changes while the thread is still stopped, triggering new > must_set_ptrace_flags, we'll deal with it before resuming. But I don't > know if this would interact well with your wrapper concerns. > Yeah, badly. > - Perhaps at the end of linux_arch_setup? AIUI this will be after > everything you're worried about wrappers. Something like that, yes. gdb/linux-nat.c also does something like that: static void linux_child_post_startup_inferior (struct target_ops *self, ptid_t ptid) { linux_init_ptrace (ptid_get_pid (ptid), 0); } I think we should rename gdbserver's target_ops:target_arch_setup method/hook to target_post_create_inferior along the way, and then linux-low.c's implementation can both call linux_arch_setup and set the ptrace options. Only Linux implements that target_ops method currently, so it should be trivial. Thanks, Pedro Alves