From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13596 invoked by alias); 12 Jan 2016 12:05:40 -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 13581 invoked by uid 89); 12 Jan 2016 12:05:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=D*be, Tell, philippewaroquiersskynetbe, philippe.waroquiers@skynet.be 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, 12 Jan 2016 12:05:38 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 6D0708E25A; Tue, 12 Jan 2016 12:05:37 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0CC5YiJ028406; Tue, 12 Jan 2016 07:05:35 -0500 Message-ID: <5694EC0E.2080904@redhat.com> Date: Tue, 12 Jan 2016 12:05: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, scox@redhat.com Subject: Re: [PATCH v4] Implement 'catch syscall' for gdbserver References: <1449196006-13759-2-git-send-email-jistone@redhat.com> <1452308954-13679-1-git-send-email-jistone@redhat.com> In-Reply-To: <1452308954-13679-1-git-send-email-jistone@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-01/txt/msg00215.txt.bz2 On 01/09/2016 03:09 AM, Josh Stone wrote: > > 2016-01-08 Josh Stone > Philippe Waroquiers > > * gdb.texinfo (Remote Configuration): List the QCatchSyscalls packet. > (Stop Reply Packets): List the syscall entry and return stop reasons. > (General Query Packets): Describe QCatchSyscalls, and add it to the > table and detailed list of stub features. > "table of detailed", I think. > @@ -648,6 +658,12 @@ handle_extended_wait (struct lwp_info **orig_event_lwp, int wstat) > event_thr->last_resume_kind = resume_continue; > event_thr->last_status.kind = TARGET_WAITKIND_IGNORE; > > + /* Update syscall state in the new lwp, effectively mid-syscall too. > + The client really should send a new list to catch, in case the > + architecture changed, but for ANY_SYSCALL it doesn't matter. */ > + event_lwp->syscall_state = TARGET_WAITKIND_SYSCALL_ENTRY; > + proc->syscalls_to_catch = syscalls_to_catch; The tone of this comment sounds to me as if the client should always send a new list, just in case, but for some odd reason it sometimes doesn't. I think we want to convey the opposite, like: /* Update syscall state in the new lwp, effectively mid-syscall too. */ event_lwp->syscall_state = TARGET_WAITKIND_SYSCALL_ENTRY; /* Restore the list to catch. Don't rely on the client, which is free to avoid sending a new list when the architecture doesn't change. Also, for ANY_SYSCALL, the architecture doesn't really matter. */ proc->syscalls_to_catch = syscalls_to_catch; > > static int > +linux_supports_catch_syscall (void) > +{ > + return (the_low_target.get_syscall_trapinfo != NULL > + && linux_supports_tracesysgood()); Space: "linux_supports_tracesysgood ()" > > +proc test_catch_syscall_execve {} { > + global gdb_prompt decimal > + > + with_test_prefix "execve" { > + > + # Tell the test program we want an execve. > + gdb_test_no_output "set do_execve = 1" > + > + # Check for entry/return across the execve, making sure that the > + # syscall_state isn't lost when turning into a new process. > + insert_catch_syscall_with_arg "execve" > + check_continue "execve" > + > + # Remotes that don't track exec may report the raw SIGTRAP for it. > + # If we use stepi now, we'll get a consistent trap for all targets. > + gdb_test "stepi" ".*" "step after execve" Why is it important to do this raw SIGTRAP handling? What happens if you don't do this? Won't those targets already FAIL the check_continue tests? Thanks, Pedro Alves