Re: [PATCH] arm reversible : <phase_2_complete>

[chandra krishnappa <chandra_roadking at yahoo dot com>]

Hi Yao and Oza,

Thanks for your comments and hints.. Yes, I wish to try test and submit test scripts soon. some hurdles to find time for testing.. will sort out and submit as soon as possible..

Thanks & Regards,
-Chandra K


--- On Mon, 10/17/11, oza Pawandeep <oza.pawandeep@gmail.com> wrote:

> From: oza Pawandeep <oza.pawandeep@gmail.com>
> Subject: Re: [PATCH] arm reversible : <phase_2_complete>
> To: "Yao Qi" <yao@codesourcery.com>
> Cc: gdb-patches@sourceware.org
> Date: Monday, October 17, 2011, 9:55 AM
> 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 <yao@codesourcery.com>
> 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. ÂBeside these fails, I find there
> are some GDB internal
> > errors in test result:
> >
> > stepi^M
> > ../../gdb/gdb/breakpoint.c:12523: internal-error:
> > insert_single_step_breakpoint: Assertion
> `single_step_breakpoints[1] ==
> > NULL' failed.
> >
> > stepi^M
> > ../../gdb/gdb/infrun.c:1804: internal-error: resume:
> Assertion
> > `!(singlestep_breakpoints_inserted_p && step)'
> failed.
> >
> > --
> > Yao (éå)
> >
>