From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7833 invoked by alias); 13 Dec 2012 14:08:02 -0000 Received: (qmail 7762 invoked by uid 22791); 13 Dec 2012 14:08:00 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from na3sys009aog134.obsmtp.com (HELO na3sys009aog134.obsmtp.com) (74.125.149.83) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 13 Dec 2012 14:07:53 +0000 Received: from mx10.qnx.com ([209.226.137.110]) (using TLSv1) by na3sys009aob134.postini.com ([74.125.148.12]) with SMTP ID DSNKUMnhNzBAs7n4Cr2Tr8r3WP1CbzgTqvZq@postini.com; Thu, 13 Dec 2012 06:07:53 PST Received: by mx10.qnx.com (Postfix, from userid 500) id 38D7221173; Thu, 13 Dec 2012 09:07:51 -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 mx10.qnx.com (Postfix) with ESMTPS id B12CD20E13; Thu, 13 Dec 2012 09:07:50 -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; Thu, 13 Dec 2012 09:07:50 -0500 Message-ID: <50C9E136.3030107@qnx.com> Date: Thu, 13 Dec 2012 14:08: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: Yao Qi CC: "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> In-Reply-To: <50C93022.5000402@codesourcery.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/msg00442.txt.bz2 On 12-12-12 08:32 PM, Yao Qi wrote: > On 12/12/2012 11:42 PM, Aleksandar Ristovski wrote: >> >> This is generic for a given OS that happens to increment instruction >> pointer to allow user code to e.g. set errno. >> >> I provided only arm implementation, but other target cpus would need the >> same if they implement software single stepping. >> >> Increment is cpu specific for a given architecture. >> > > 'software single step' is implemented differently in the backend of each > port and your 'syscall_pc_increment' depends on the arch as well, so a > gdbarch hook is not needed here. > > 'gdbarch' stands for a certain general architecture, such as arm, mips, > and etc. 'gdbarch_tdep' contains the details of the cpus under this > architecture. Yes, I see your point, though I would say gdbarch stands for a certain architecture such as arm-nto, arm-linux, etc... therefore, cpu/os combination, not cpu only. 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. Of course, the alternative is to not introduce concept from a) at all and do everything in my cpu-os-tdep.c which is how I have it set up now in our port. > > 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. --- Aleksandar