From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23455 invoked by alias); 17 Oct 2011 04:25:37 -0000 Received: (qmail 23430 invoked by uid 22791); 17 Oct 2011 04:25:34 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 17 Oct 2011 04:25:19 +0000 Received: by wwf10 with SMTP id 10so1071051wwf.12 for ; Sun, 16 Oct 2011 21:25:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.153.211 with SMTP id l19mr6136604wbw.51.1318825518522; Sun, 16 Oct 2011 21:25:18 -0700 (PDT) Received: by 10.180.105.69 with HTTP; Sun, 16 Oct 2011 21:25:18 -0700 (PDT) In-Reply-To: <4E9B8B08.9060509@codesourcery.com> References: <998639.46560.qm@web112516.mail.gq1.yahoo.com> <321260.58442.qm@web112504.mail.gq1.yahoo.com> <1316327455.23344.YahooMailNeo@web112509.mail.gq1.yahoo.com> <1316404058.27177.YahooMailNeo@web112502.mail.gq1.yahoo.com> <1318650316.91503.YahooMailNeo@web112508.mail.gq1.yahoo.com> <4E9952EA.5040805@codesourcery.com> <4E998B76.8020803@codesourcery.com> <4E9B8B08.9060509@codesourcery.com> Date: Mon, 17 Oct 2011 04:28:00 -0000 Message-ID: Subject: Re: [PATCH] arm reversible : From: oza Pawandeep To: Yao Qi Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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: 2011-10/txt/msg00454.txt.bz2 Hi Yao, Thanks for your comments. please find my comments below. 1) Yao: x86 assembly will not compiled and run for arm target, so they don't > make fails here. Beside these fails, I find there are some GDB internal > errors in test result Oza: what I meant here was: x86 assembly might have failed to compile even and gdb test results might be including that. anyway, arm assembly has to be written separately, which I guess Chandra K. might be doing. 2) Yao: Looks like most of indentaiton of your 2nd line of comment is incorrect. I'll point some of them out, but I may miss some. I suggest that you can find some good editor which can highlight trailing spaces and too-long line easily. Oza: this is one thing I have been struggling with, I have been moving this patch back and forth from windows to linux and using source insight, vi, xemacs an d finally when I paste it to google mail the space gets distorted. I need to find out what I can do. sorry about repeating space mistakes. 3) Yes, only 16-bit thumb is supported, but you should report a warning or error when encounter a 32-bit thumb insn, and skip it. In arm_process_record, you assume that all thumb insns are 16-bit, which is not correct. Please reference "thumb_process_displaced_insn". Oza: I will include this logic. 4) Yao: I don't understand why coproc insn is not handled for process record here. is it in phase_3? Oza: initially I had planned to put both coprocessor and arm_extension_space insn in phase 3. but I am going to update this patch with arm__extension_space insn atleast. as far as coprocessor insns are concerned, I could not find any API which could be used to read coprocessor register values. I had sent email regarding the same long back: but I did not get response, so I moved it to phase 3. If you could point me out the way to read coprocessor register values: I will try to implement on phase 2. Thanks Yao, Regards, Oza. On Mon, Oct 17, 2011 at 7:25 AM, Yao Qi wrote: > On 10/16/2011 12:34 AM, oza Pawandeep wrote: >> Hi Yao, >> >> first of all thank you for your comments, will be sending the patch >> soon with your comments incorporated as much as possible. >> thank you again for sending test results; >> >> I suppose failed test case might be including >> >> 1) system call support >> 2) signal support >> 3) any other linux ABI support >> 4) there are some programs on x86 assembly which needs to be written >> for ARM and put separately. > > x86 assembly will not compiled and run for arm target, so they don't > make fails here. =C2=A0Beside these fails, I find there are some GDB inte= rnal > errors in test result: > > stepi^M > ../../gdb/gdb/breakpoint.c:12523: internal-error: > insert_single_step_breakpoint: Assertion `single_step_breakpoints[1] =3D= =3D > NULL' failed. > > stepi^M > ../../gdb/gdb/infrun.c:1804: internal-error: resume: Assertion > `!(singlestep_breakpoints_inserted_p && step)' failed. > > -- > Yao (=E9=BD=90=E5=B0=A7) >