From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1367 invoked by alias); 14 Dec 2012 14:23:40 -0000 Received: (qmail 1343 invoked by uid 22791); 14 Dec 2012 14:23:39 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from na3sys009aog121.obsmtp.com (HELO na3sys009aog121.obsmtp.com) (74.125.149.145) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 14 Dec 2012 14:23:34 +0000 Received: from mx20.qnx.com ([72.1.200.103]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKUMs2X3+tn3Nr8krMixQy+RdcZI8Zz8H9@postini.com; Fri, 14 Dec 2012 06:23:34 PST Received: by mx20.qnx.com (Postfix, from userid 500) id CC0E820E57; Fri, 14 Dec 2012 09:23:26 -0500 (EST) Received: from exhts.ott.qnx.com (exhts1 [10.222.2.110]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx20.qnx.com (Postfix) with ESMTPS id 02B6220E3B; Fri, 14 Dec 2012 09:23:26 -0500 (EST) Received: from [10.222.96.215] (10.222.96.215) by exhts1.ott.qnx.com (10.222.2.25) with Microsoft SMTP Server id 14.2.318.1; Fri, 14 Dec 2012 09:23:25 -0500 Message-ID: <50CB365D.5070902@qnx.com> Date: Fri, 14 Dec 2012 14:23:00 -0000 From: Aleksandar Ristovski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Pedro Alves 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> <50CA4CF4.8070307@redhat.com> In-Reply-To: <50CA4CF4.8070307@redhat.com> Content-Type: text/plain; charset="UTF-8"; format=flowed 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/msg00499.txt.bz2 On 12-12-13 04:47 PM, Pedro Alves wrote: > 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. This seems just wrong to me, to install a breakpoint when answering a question. > >>> 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. > Well, I plan to, but can't provide any ETA. No problem - there is no urgency in this, at least we have exchanged thoughts on where would this fit (it doesn't fit anywhere ATM :-) ). I'll stick with providing my own software_single_step. Consider the patch abandoned. Thanks, Aleksandar