From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57103 invoked by alias); 12 Sep 2015 02:27:45 -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 57088 invoked by uid 89); 12 Sep 2015 02:27:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_40,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no 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; Sat, 12 Sep 2015 02:27:43 +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 786E22F2FB9; Sat, 12 Sep 2015 02:27:42 +0000 (UTC) Received: from localhost (unused-10-15-17-51.yyz.redhat.com [10.15.17.51]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8C2RfVS011846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 11 Sep 2015 22:27:42 -0400 From: Sergio Durigan Junior To: Josh Stone Cc: gdb-patches@sourceware.org, philippe.waroquiers@skynet.be, palves@redhat.com Subject: Re: [RFC] reviving 'catch syscall' for gdbserver References: <55F3838A.4010005@redhat.com> X-URL: http://blog.sergiodj.net Date: Sat, 12 Sep 2015 02:27:00 -0000 In-Reply-To: <55F3838A.4010005@redhat.com> (Josh Stone's message of "Fri, 11 Sep 2015 18:44:42 -0700") Message-ID: <87vbbgpe1u.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00263.txt.bz2 On Friday, September 11 2015, Josh Stone wrote: > Hi all, > > I've been using Philippe's QCatchSyscalls patch[1] for gdbserver, and > I'd like to reopen the discussion about merging this patch. Philippe > told me would be fine with me taking this up, as he doesn't have time to > work on it now. > > [1] https://sourceware.org/ml/gdb-patches/2013-09/msg00992.html > > I've rebased the patch onto current gdb.git master, attached. Some > things are simplified by various refactoring done in the last two years, > but otherwise I didn't change any capability from what he had. > > I haven't included formalities like ChangeLogs here, because I would > like to get basic consensus on the approach first. I also don't know > the right way to approach authorship here, between what Philippe > originally wrote and my changes since, for what's ultimately committed. > > I tested catch-syscall.exp on Fedora 22 x86_64, for targets unix, > native-gdbserver, and native-extended-gdbserver, and all passed. > > Philippe pointed me to his last summary of issues, which I'd like to > start the discussion with: > https://sourceware.org/ml/gdb-patches/2013-10/msg00321.html Hi Josh, First of all, thanks for the patch and for reviving. This e-mail is not really an in-depth reply; just a few things I would like to mention from the top of my head. >> * QCatchSyscalls contains target specific numbers (this is the >> above comment) >> => have gdbserver handling QCatchSyscalls packet per inferior > > Does this still need to be per-inferior? I do understand that syscall > numbers may differ, e.g. from i686 to x86_64 on the same target. Are > there any other examples of such things that are dealt with separately? I pushed: (discussion: ) meanwhile, which should help address this issue (though it doesn't fix the whole problem). You might be interested in reading https://sourceware.org/bugzilla/show_bug.cgi?id=10737 as well. >> * 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. > > I notice that fork and vfork events have since been implemented on their > own as simple qSupported flags. So I guess this idea of a generic > QInsertCatchPoint idea was dropped? That's my understanding as well. I'd say go ahead with QCatchSyscalls. >> * 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. > > I guess this is referring gdb's simple toggling, vs gdbserver's ENOSYS > method of detecting syscall entry vs return. Can someone point to the > bug in gdb's flip/flop? (strace is also a toggler, btw) > > FWIW, I think it is possible for Linux to know this precisely. AFAIK > the only way to catch a syscall return is with PTRACE_SYSCALL from a > syscall entry *or* from one of the mid-syscall events, like a > PTRACE_EVENT_FORK. Any other time, a syscall stop can only be entry. > > I can see how flip/flop might get confused if 'catch syscall' was only > enabled when the target was already stopped on that fork, for instance. > But if you mark that fork like being in an entry, then it will toggle > to return correctly afterward. Enabling 'catch syscall' at any other > time should start at IGNORE, so the next is then entry. > > But I expect I'm missing things. I'd like to hear what other demons are > lurking around this... > > (I also know Sergio was tinkering with a ptrace patch to distinguish > entry/return precisely in the kernel, which would be nice for all.) I'll see if I can have some time this weekend to resume my work on this. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/