From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32323 invoked by alias); 4 Oct 2013 17:40:26 -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 32313 invoked by uid 89); 4 Oct 2013 17:40:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_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 ESMTP; Fri, 04 Oct 2013 17:40:23 +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 (8.14.4/8.14.4) with ESMTP id r94HeHvV000520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Oct 2013 13:40:18 -0400 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 r94HeFVp001531; Fri, 4 Oct 2013 13:40:16 -0400 Message-ID: <524EFD7F.3060903@redhat.com> Date: Fri, 04 Oct 2013 17:40:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: lgustavo@codesourcery.com CC: Philippe Waroquiers , Sergio Durigan Junior , gdb-patches@sourceware.org Subject: Re: RFA [PATCH v4] Implement 'catch syscall' for gdbserver (was Re: RFA [PATCH v3] Implement 'catch syscall' for gdbserver) References: <1379796907.5980.20.camel@soleil> <1380467062.3567.52.camel@soleil> <524E428B.4010508@codesourcery.com> In-Reply-To: <524E428B.4010508@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-10/txt/msg00146.txt.bz2 On 10/04/2013 05:22 AM, Luis Machado wrote: > On 09/29/2013 12:04 PM, Philippe Waroquiers wrote: >> ChangeLog >> 2013-xx-yy Philippe Waroquiers >> >> * NEWS: Document new QcatchSyscalls packet and its use >> in x86/amd64 linux gdbserver and Valgrind gdbserver. >> * remote.c (PACKET_QCatchSyscalls): New. >> (remote_protocol_features): Add QcatchSyscalls. >> (remote_set_syscall_catchpoint): New function. >> (remote_parse_stop_reply): New stop reasons syscall_entry >> and syscall_return. >> (init_remote_ops): Registers remote_set_syscall_catchpoint >> and the config commands for PACKET_QCatchSyscalls. > > I'm late to the party, but i've always wondered why we have all these > different "insert__catchpoint" and "remove__catchpoint" > functions to accomplish tasks that seem to be very similar in nature. > > Not saying we should go this route for this patch, but we may want to > consider a more generic RSP packet for catchpoints. Something like the > following: > > QInsertCatchpoint:[syscall|fork|exec|vfork|unload|...] > QRemoveCatchpoint:[syscall|fork|exec|vfork|unload|...] > > ... or even communicate catchpoints through Z/z packets, though that > would be a more radical approach. You know, you actually have a very good point. It actually looks unfortunate to come up with new packets that don't incorporate all the nice new features we've added to the Z/z packets recently, such as target side conditions and commands. The issue I see is that syscall (and other catchpoints) have arguments. What would you pass to QRemoveCatchpoint to remove a previous catchpoint? Sounds like QInsertCatchpoint would need to return a unique target-side identifier, that QRemoveCatchpoint would then use? There's also the issue with the fact that for Z packets, the RSP specifies that a second Z packet seen for the same address replaces the previous packet, because it might have happened that GDB and the server lost sync for a bit, and the second packet was actually a retransmission. Making QInsertCatchpoint return a reference conflicts with that. Unless perhaps we make GDB send a unique id along as well... I think the RSP used to always send a sequence number with each packet, and that has been removed a long time ago. I wish I know why it was removed. It would solve these issues. Maybe we should add it back. > Anyway, just throwing a few ideas since i've been dealing with some of > the issues with catchpoints, forking and gdbserver as well. Yeah. -- Pedro Alves