This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] arm reversible : <phase_2_complete>
- From: chandra krishnappa <chandra_roadking at yahoo dot com>
- To: Yao Qi <yao at codesourcery dot com>, oza Pawandeep <oza dot pawandeep at gmail dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 17 Oct 2011 08:06:59 -0700 (PDT)
- Subject: Re: [PATCH] arm reversible : <phase_2_complete>
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,
--- On Mon, 10/17/11, oza Pawandeep <firstname.lastname@example.org> wrote:
> From: oza Pawandeep <email@example.com>
> Subject: Re: [PATCH] arm reversible : <phase_2_complete>
> To: "Yao Qi" <firstname.lastname@example.org>
> Cc: email@example.com
> Date: Monday, October 17, 2011, 9:55 AM
> Hi Yao,
> Thanks for your comments. please find my comments below.
> 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
> Chandra K. might be doing.
> 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
> 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
> 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
> 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,
> On Mon, Oct 17, 2011 at 7:25 AM, Yao Qi <firstname.lastname@example.org>
> > 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
> >> 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 ==
> > NULL' failed.
> > stepi^M
> > ../../gdb/gdb/infrun.c:1804: internal-error: resume:
> > `!(singlestep_breakpoints_inserted_p && step)'
> > --
> > Yao (éå)