From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2168 invoked by alias); 22 Jul 2013 07:30:32 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 2151 invoked by uid 89); 22 Jul 2013 07:30:32 -0000 X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_20,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RDNS_NONE,TW_EG autolearn=no version=3.3.1 Received: from Unknown (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 22 Jul 2013 07:30:31 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1V1AZb-0005uJ-LN from Yao_Qi@mentor.com ; Mon, 22 Jul 2013 00:30:23 -0700 Received: from SVR-ORW-FEM-03.mgc.mentorg.com ([147.34.97.39]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Jul 2013 00:30:23 -0700 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-03.mgc.mentorg.com (147.34.97.39) with Microsoft SMTP Server id 14.2.247.3; Mon, 22 Jul 2013 00:30:22 -0700 Message-ID: <51ECDF5D.6010207@codesourcery.com> Date: Mon, 22 Jul 2013 07:30:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Jan Kratochvil CC: Terry Guo , Hui Zhu , Subject: Re: Reverse debugging for arm baremetal targets? References: <20130722063842.GA24373@host2.jankratochvil.net> In-Reply-To: <20130722063842.GA24373@host2.jankratochvil.net> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2013-07/txt/msg00073.txt.bz2 On 07/22/2013 02:38 PM, Jan Kratochvil wrote: > But the OS dependent part seems to be missing there: > arm-tdep.h: > /* Parse swi insn args, sycall record. */ > int (*arm_swi_record) (struct regcache *regcache); > - which does not seem to be set anywhere > I raised this question during the code review, and Oza (the author) wanted to do them in phase 3, which handles OS related stuff, such as syscall. What we have in trunk is phase 2. > So the current set_gdbarch_process_record initialization could be possibly > moved to arm-tdep.c. But I did not play more with it. Right, the existing Oza's work in trunk is about ARM reversed debugging, without OS stuff. Probably we should call set_gdbarch_process_record in arm-tdep.c, but not sure how good or bad the results are. -- Yao (齐尧)