From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106701 invoked by alias); 10 Mar 2015 04:53:05 -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 106692 invoked by uid 89); 10 Mar 2015 04:53:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_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; Tue, 10 Mar 2015 04:53:03 +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 (8.14.4/8.14.4) with ESMTP id t2A4r0XC030601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 10 Mar 2015 00:53:00 -0400 Received: from localhost (dhcp-10-15-16-169.yyz.redhat.com [10.15.16.169]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2A4qx1H011082 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Mar 2015 00:53:00 -0400 From: Sergio Durigan Junior To: Yao Qi Cc: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [RFC] Support command "catch syscall" properly on different targets References: <1425047015-1906-1-git-send-email-qiyaoltc@gmail.com> <877fv3kqx1.fsf@redhat.com> <86lhjei8md.fsf@gmail.com> <54F5A90E.8050704@redhat.com> <87bnkaklbe.fsf@redhat.com> <868ufahylt.fsf@gmail.com> <87lhj9zsss.fsf@redhat.com> <86vbiags7c.fsf@gmail.com> X-URL: http://blog.sergiodj.net Date: Tue, 10 Mar 2015 04:53:00 -0000 In-Reply-To: <86vbiags7c.fsf@gmail.com> (Yao Qi's message of "Mon, 09 Mar 2015 14:29:11 +0000") Message-ID: <87twxtv4gk.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00232.txt.bz2 On Monday, March 09 2015, Yao Qi wrote: > Sergio Durigan Junior writes: > >> So, as I said in my previous messages, I don't think that making the >> "catch syscall" command to fail on the exec target. >> >> What do you think of the attached patch (applies on top of your patch, >> rebased to the current HEAD)? It implements what I proposed, but in a >> different way. If the target is "None" (no binary loaded) or "exec" >> (inferior loaded but never started), then it displays a warning but >> still creates the catchpoint. The actual check for these targets >> happens in the insert_catch_syscall function, which is called when we >> already know if the target actually supports the syscall catchpoint. >> >> Maybe I forgot to cover some corner case, but I still think we should >> support "catch syscall" when no inferior has been started. > > I don't have a strong opinion against your approach. Since "catch > point" is only supported on some arches on linux native target, I think > it is OK to leave gdbarch_get_syscall_number_p checking in > catch_syscall_command_1, so I withdraw my patch. Right. If you withdraw your patch, then my patch doesn't make sense :-). > However, when I play with your patch, I find GDB can disable catch point if it > isn't inserted successfully, in breakpoint.c:insert_bp_location, > > else if (bl->owner->type == bp_catchpoint) > { > int val; > > gdb_assert (bl->owner->ops != NULL > && bl->owner->ops->insert_location != NULL); > > val = bl->owner->ops->insert_location (bl); > if (val) > { > bl->owner->enable_state = bp_disabled; > > if (val == 1) > warning (_("\ > Error inserting catchpoint %d: Your system does not support this type\n\ > of catchpoint."), bl->owner->number); > else > warning (_("Error inserting catchpoint %d."), bl->owner->number); > } Yeah, this is the reason my patch was returning 1 on insert_catch_syscall. The good thing about this is that GDB also keeps the record for this type of catchpoint, so that the warning isn't repeated over and over. But you probably knew there :-). > as shown below, > > (gdb) target remote :1234 > Remote debugging using :1234 > Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. > 0x00007ffff7ddb2d0 in ?? () from /lib64/ld-linux-x86-64.so.2 > (gdb) c > Continuing. > warning: Error inserting catchpoint 1: Your system does not support this type > of catchpoint. > .... > > (gdb) info breakpoints > Num Type Disp Enb Address What > 1 catchpoint keep n syscall "open" > > According this observation, I don't see the need check > gdbarch_get_syscall_number_p in catch_syscall_command_1. Probably we > can remove it. Yeah, it can be removed. This will make the 'catch syscall' command more similar to the other catchpoint commands, although I liked the idea of your patch... Cheers, -- Sergio GPG key ID: 0x65FC5E36 Please send encrypted e-mail if possible http://sergiodj.net/