From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9662 invoked by alias); 13 Dec 2012 21:47:54 -0000 Received: (qmail 9653 invoked by uid 22791); 13 Dec 2012 21:47:53 -0000 X-SWARE-Spam-Status: No, hits=-7.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 13 Dec 2012 21:47:45 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qBDLlYfP019419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Dec 2012 16:47:35 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qBDLlWiR028075; Thu, 13 Dec 2012 16:47:33 -0500 Message-ID: <50CA4CF4.8070307@redhat.com> Date: Thu, 13 Dec 2012 21:47:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Aleksandar Ristovski CC: Yao Qi , "gdb-patches@sourceware.org" Subject: Re: [patch] gdbarch_syscall_pc_increment References: <50C8937A.1090905@qnx.com> <50C8A2FA.5000105@codesourcery.com> <50C8A5FF.9090902@qnx.com> <50C93022.5000402@codesourcery.com> <50C9E136.3030107@qnx.com> In-Reply-To: <50C9E136.3030107@qnx.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2012-12/txt/msg00478.txt.bz2 On 12/13/2012 02:07 PM, Aleksandar Ristovski wrote: > In this patch, we are talking about two things: > > a) the concept of syscall behaving as a conditional branch with uncomputable condition (i.e. gdb can not really compute whether the branch will be taken or not). This is a concept specific to a given kernel implementation of system calls and as such belongs to gdbarch. > > b) The amount by which pc may be incremented if the branch is taken. For an os that has a), this is cpu specific. It may also be dependent on the instruction set mode on e.g. arm (this is why frame is being passed). > > Where does this belong: in the case here, the line is a bit blurry since a) is generic concept applicable for all cpus for a given os thus definitely belonging to gdbarch. b) is cpu concept and strictly speaking belongs to gdbarch_tdep. However, since a) can also answer b) I see no point in further breaking it down. The interface is not pretty, but you can just install an additional breakpoint from your OS's tdep->syscall_next_pc hook or gdbarch_software_single_step wrapper hook. See e.g.,: /* Find the next PC after the current instruction executes. In some cases we can not statically determine the answer (see the IT state handling in this function); in that case, a breakpoint may be inserted in addition to the returned PC, which will be used to set another breakpoint by our caller. */ static CORE_ADDR thumb_get_next_pc_raw (struct frame_info *frame, CORE_ADDR pc) { ... /* Set a breakpoint on the following instruction. */ gdb_assert ((itstate & 0x0f) != 0); arm_insert_single_step_breakpoint (gdbarch, aspace, MAKE_THUMB_ADDR (pc)); ... I believe other ports do similar things in similar cases. >> b.t.w, I don't see how 'set_gdbarch_syscall_pc_increment' is called in >> your patch. >> > > No, as we have not yet contributed arm-nto-tdep.c to FSF. When do you plan to do so? I'm afraid we shouldn't be accepting unused hooks in the tree. -- Pedro Alves