From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14885 invoked by alias); 12 Dec 2012 15:43:05 -0000 Received: (qmail 14865 invoked by uid 22791); 12 Dec 2012 15:43:03 -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 na3sys009aog125.obsmtp.com (HELO na3sys009aog125.obsmtp.com) (74.125.149.153) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 12 Dec 2012 15:42:58 +0000 Received: from mx10.qnx.com ([209.226.137.110]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKUMimAZL2YrzRWgdnE6I2i6lFcpPI+Vmo@postini.com; Wed, 12 Dec 2012 07:42:58 PST Received: by mx10.qnx.com (Postfix, from userid 500) id 68E9721173; Wed, 12 Dec 2012 10:42:56 -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 DA49C21167; Wed, 12 Dec 2012 10:42:55 -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; Wed, 12 Dec 2012 10:42:55 -0500 Message-ID: <50C8A5FF.9090902@qnx.com> Date: Wed, 12 Dec 2012 15:43: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> In-Reply-To: <50C8A2FA.5000105@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/msg00394.txt.bz2 On 12-12-12 10:30 AM, Yao Qi wrote: > Hi, > I don't understand why do you add a gdbarch hook, but use it only in a > target-specific part? The goal of gdbarch hooks is about hiding the > difference of ports and giving a common interface to the common part of > GDB. If your issue is arm specific, we don't need this new gdbarch hook > at all. 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. > > If I understand your problem correctly, you have to define your own > function 'arm_neutrino_syscall_next_pc' in your file > arm-neutrino-tdep.c, and install it on function pointer > 'syscall_next_pc' (in 'struct gdbarch_tdep' in arm-tdep.h) in > 'arm_neutrino_init_abi'. Please have a look on how 'syscall_next_pc' is > set in arm-linux-tdep.c. Then you can compute the pc for your own os in > 'arm_neutrino_syscall_next_pc'. Hope it helps. No, the destination is not a single address as we do not know the outcome of the syscall. It may come back with the instruction pointer of the next instruction after 'svc' but also 4 bytes later (4 bytes in our case, some other kernel may implement it differently). Hope this clarifies, Aleksandar