From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12014 invoked by alias); 9 Oct 2013 21:54:21 -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 12005 invoked by uid 89); 9 Oct 2013 21:54:21 -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,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mailrelay008.isp.belgacom.be Received: from mailrelay008.isp.belgacom.be (HELO mailrelay008.isp.belgacom.be) (195.238.6.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 09 Oct 2013 21:54:19 +0000 X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAJjPVVJXQucZ/2dsb2JhbAANTYc5uxmCfIE2gxkBAQEEI1YQCw4KAgIfBwICVwatenWSQIEpjhwHgmqBOQOraoFA Received: from 25.231-66-87.adsl-dyn.isp.belgacom.be (HELO [192.168.1.5]) ([87.66.231.25]) by relay.skynet.be with ESMTP; 09 Oct 2013 23:54:17 +0200 Subject: Re: RFA [PATCH v4] Implement 'catch syscall' for gdbserver (was Re: RFA [PATCH v3] Implement 'catch syscall' for gdbserver) From: Philippe Waroquiers To: Pedro Alves Cc: Sergio Durigan Junior , gdb-patches@sourceware.org In-Reply-To: <524FD8A9.2010006@redhat.com> References: <1379796907.5980.20.camel@soleil> <1380467062.3567.52.camel@soleil> <524DBA28.3070706@redhat.com> <1380837750.2217.104.camel@soleil> <524EFB00.90105@redhat.com> <524FD8A9.2010006@redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 09 Oct 2013 21:54:00 -0000 Message-ID: <1381355683.2141.68.camel@soleil> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-10/txt/msg00321.txt.bz2 On Sat, 2013-10-05 at 10:15 +0100, Pedro Alves wrote: > Hi, > > I don't have time right now for a more elaborate answer, but ... > > On 10/04/2013 06:29 PM, Pedro Alves wrote: > > > > Thinking only in terms of multi-process/thread, I'm inclined to ignore the > > "per-process" thing now, and just leave it as gdbserver making catch > > syscall apply to all processes. > > I just realized that we really can't do that. The syscall numbers > sent across the wire are the target-specific numbers. Since gdbserver > might well be debugging processes of different gdbarch's simultaneously > (see the multi-arch support patches from a while ago, the tdesc support > in gdbserver, etc.), we can't assume the same syscall array makes sense > for all processes under gdbserver's control. > Hello, Getting back to this after a period of other activitites, here is a suggested list of approaches to address the major comments given in various mails: * QCatchSyscalls contains target specific numbers (this is the above comment) => have gdbserver handling QCatchSyscalls packet per inferior * ensure QCatchSyscall packet can (in the future) be extended with a COND_LIST (similar to the Z packets). To do that, I suggest to have the QCatchSyscalls separating syscall numbers with a , rather than a ; (so that a ; can be used later to separate the list of syscalls from the COND_LIST) Note: Luis suggested the alternative to have a packet QInsertCatchPoint:[fork|syscall|exec|...] Then gdbserver will tell in QSupported that it e.g. support QInsertCatchPoint=syscall,fork For what concerns the problem of identifying which catchpoint to remove in the QRemoveCatchPoint: not too sure we need an catch point id for that. We can assume that an QInsertCatchPoint of a certain kind fully replace the previously inserted catchpoint of the same kind. A QRemoveCatchpoint removes completely the catchpoint of the same kind. I can go the QInsertCatchPoint way if it is confirmed this is a better approach. * Need to investigate the bug in gdb 'catch syscall' flip/flop logic. If this logic can be fixed, then have gdbserver and gdb using the same logic. * extend the stop reply packet to allow to return a "syscall" stop reason that does not specify if this is a syscall entry or exit. I suggest to do this even if a correct flip/flop logic can be found during the previous investigation. This 3rd syscall stop reason allow stubs to report a syscall without necessarily having the logic to differentiate entry from return. Any comments about the above approaches ? (in particular, about the choice between QCatchSyscalls and QInsertCatchPoint). Thanks Philippe