[PATCH] Makefile.in includes linux-record.c to be common for all arch. (arm-reversible>phase-3)

[PATCH] Makefile.in includes linux-record.c to be common for all arch. (arm-reversible>phase-3)

[oza Pawandeep]

Hi,

linux-record.o is added under COMMON_OBS, now <arch>-linux-tdep.c compiles.
ok to commit ?


diff -urN ./old/Makefile.in ./new/Makefile.in
--- ./old/Makefile.in   2012-06-07 09:13:32.000000000 +0530
+++ ./new/Makefile.in   2012-06-07 09:17:05.000000000 +0530
@@ -914,7 +914,7 @@
        prologue-value.o memory-map.o memrange.o \
        xml-support.o xml-syscall.o xml-utils.o \
        target-descriptions.o target-memory.o xml-tdesc.o xml-builtin.o \
-       inferior.o osdata.o gdb_usleep.o record.o gcore.o \
+       inferior.o osdata.o gdb_usleep.o linux-record.o record.o gcore.o \
        jit.o progspace.o skip.o probe.o \
        common-utils.o buffer.o ptid.o gdb-dlfcn.o common-agent.o


Regards,
Oza.

Re: [PATCH] Makefile.in includes linux-record.c to be common for all arch. (arm-reversible>phase-3)

[Yao Qi]

On 06/07/2012 11:51 AM, oza Pawandeep wrote:
> linux-record.o is added under COMMON_OBS, now <arch>-linux-tdep.c compiles.
> ok to commit ?

I feel it is useless to link linux-record.o for the ports that don't
support record at all.

If you want to support record in arm-linux, gdb/configure.tgt is the
right place to modify, IMO.  You need to add "linux-record.o" into
gdb_target_obs in "arm*-*-linux*)".

-- 
Yao (齐尧)

Re: [PATCH] Makefile.in includes linux-record.c to be common for all arch. (arm-reversible>phase-3)

[oza Pawandeep]

ok. sure will add it there as it is not currently linking.
but on the contrary 'record.o' is also under the same section
COMMON_OBS, which is also not required where no record support.
hence it is confusing.

Regards,
Oza.

On Thu, Jun 7, 2012 at 7:11 PM, Yao Qi <yao@codesourcery.com> wrote:
> On 06/07/2012 11:51 AM, oza Pawandeep wrote:
>> linux-record.o is added under COMMON_OBS, now <arch>-linux-tdep.c compiles.
>> ok to commit ?
>
> I feel it is useless to link linux-record.o for the ports t, hat don't
> support record at all.
>
> If you want to support record in arm-linux, gdb/configure.tgt is the
> right place to modify, IMO.  You need to add "linux-record.o" into
> gdb_target_obs in "arm*-*-linux*)".
>
> --
> Yao (齐尧)

Re: [PATCH] Makefile.in includes linux-record.c to be common for all arch. (arm-reversible>phase-3)

[Matt Rice]

On Thu, Jun 7, 2012 at 10:20 AM, oza Pawandeep <oza.pawandeep@gmail.com> wrote:
> ok. sure will add it there as it is not currently linking.
> but on the contrary 'record.o' is also under the same section
> COMMON_OBS, which is also not required where no record support.
> hence it is confusing.

I think that because record.o implements gdb commands, we want
commands to be available universally
e.g. we want an error that support for a command is not available in a
build of gdb, rather than 'Undefined command.'

where linux-record appears to be plumbing, thus not necessary.

Re: [PATCH] Makefile.in includes linux-record.c to be common for all arch. (arm-reversible>phase-3)

[oza Pawandeep]

ok. It is clear now.
shall incorporate linux-record where Yao suggested.

Regards,
Oza.

On Fri, Jun 8, 2012 at 11:39 AM, Matt Rice <ratmice@gmail.com> wrote:
> On Thu, Jun 7, 2012 at 10:20 AM, oza Pawandeep <oza.pawandeep@gmail.com> wrote:
>> ok. sure will add it there as it is not currently linking.
>> but on the contrary 'record.o' is also under the same section
>> COMMON_OBS, which is also not required where no record support.
>> hence it is confusing.
>
> I think that because record.o implements gdb commands, we want
> commands to be available universally
> e.g. we want an error that support for a command is not available in a
> build of gdb, rather than 'Undefined command.'
>
> where linux-record appears to be plumbing, thus not necessary.

Re: [PATCH] Makefile.in includes linux-record.c to be common for all arch. (arm-reversible>phase-3)

[oza Pawandeep]

please ind the latest patch which includes compilation of linux-record for ARM.

diff -urN orig/configure.tgt new/configure.tgt
--- orig/configure.tgt	2012-06-18 12:36:47.274501400 +0530
+++ new/configure.tgt	2012-06-18 12:31:47.335501400 +0530
@@ -76,7 +76,7 @@
 arm*-*-linux*)
 	# Target: ARM based machine running GNU/Linux
 	gdb_target_obs="arm-tdep.o arm-linux-tdep.o glibc-tdep.o \
-			solib-svr4.o symfile-mem.o linux-tdep.o"
+			solib-svr4.o symfile-mem.o linux-tdep.o linux-record.o"
 	build_gdbserver=yes
 	;;
 arm*-*-netbsd* | arm*-*-knetbsd*-gnu)

ok to check in ?

Regards,
Oza.

On Fri, Jun 8, 2012 at 6:13 PM, oza Pawandeep <oza.pawandeep@gmail.com> wrote:
> ok. It is clear now.
> shall incorporate linux-record where Yao suggested.
>
> Regards,
> Oza.
>
> On Fri, Jun 8, 2012 at 11:39 AM, Matt Rice <ratmice@gmail.com> wrote:
>> On Thu, Jun 7, 2012 at 10:20 AM, oza Pawandeep <oza.pawandeep@gmail.com> wrote:
>>> ok. sure will add it there as it is not currently linking.
>>> but on the contrary 'record.o' is also under the same section
>>> COMMON_OBS, which is also not required where no record support.
>>> hence it is confusing.
>>
>> I think that because record.o implements gdb commands, we want
>> commands to be available universally
>> e.g. we want an error that support for a command is not available in a
>> build of gdb, rather than 'Undefined command.'
>>
>> where linux-record appears to be plumbing, thus not necessary.

Re: [PATCH] Makefile.in includes linux-record.c to be common for all arch. (arm-reversible>phase-3)

[Yao Qi]

On 06/18/2012 05:08 PM, oza Pawandeep wrote:
> diff -urN orig/configure.tgt new/configure.tgt
> --- orig/configure.tgt	2012-06-18 12:36:47.274501400 +0530
> +++ new/configure.tgt	2012-06-18 12:31:47.335501400 +0530
> @@ -76,7 +76,7 @@
>  arm*-*-linux*)
>  	# Target: ARM based machine running GNU/Linux
>  	gdb_target_obs="arm-tdep.o arm-linux-tdep.o glibc-tdep.o \
> -			solib-svr4.o symfile-mem.o linux-tdep.o"
> +			solib-svr4.o symfile-mem.o linux-tdep.o linux-record.o"
>  	build_gdbserver=yes
>  	;;
>  arm*-*-netbsd* | arm*-*-knetbsd*-gnu)
> 
> ok to check in ?

It is not good to post the same change twice in different mails.  This
change makes no sense until your 'arm-syscall record' patch is approved.
 I noticed that this change has been included in your 'arm-syscall
record' patch, so I think patch here doesn't have to reviewed.

-- 
Yao (齐尧)

Re: [PATCH] Makefile.in includes linux-record.c to be common for all arch. (arm-reversible>phase-3)

[oza Pawandeep]

Yes I agree; as I integrated both of them and post them at once.
sorry about confusion; this patch has to be ignored.

In fact I wanted this patch to be approved first because without which
sys call patch would not compile.

Regards,
Oza.

On Mon, Jun 18, 2012 at 2:54 PM, Yao Qi <yao@codesourcery.com> wrote:
> On 06/18/2012 05:08 PM, oza Pawandeep wrote:
>> diff -urN orig/configure.tgt new/configure.tgt
>> --- orig/configure.tgt        2012-06-18 12:36:47.274501400 +0530
>> +++ new/configure.tgt 2012-06-18 12:31:47.335501400 +0530
>> @@ -76,7 +76,7 @@
>>  arm*-*-linux*)
>>       # Target: ARM based machine running GNU/Linux
>>       gdb_target_obs="arm-tdep.o arm-linux-tdep.o glibc-tdep.o \
>> -                     solib-svr4.o symfile-mem.o linux-tdep.o"
>> +                     solib-svr4.o symfile-mem.o linux-tdep.o linux-record.o"
>>       build_gdbserver=yes
>>       ;;
>>  arm*-*-netbsd* | arm*-*-knetbsd*-gnu)
>>
>> ok to check in ?
>
> It is not good to post the same change twice in different mails.  This
> change makes no sense until your 'arm-syscall record' patch is approved.
>  I noticed that this change has been included in your 'arm-syscall
> record' patch, so I think patch here doesn't have to reviewed.
>
> --
> Yao (齐尧)
>
>

Re: [PATCH] Makefile.in includes linux-record.c to be common for all arch. (arm-reversible>phase-3)

[Hui Zhu]

On Mon, Jun 18, 2012 at 7:49 PM, oza Pawandeep <oza.pawandeep@gmail.com> wrote:
> Yes I agree; as I integrated both of them and post them at once.
> sorry about confusion; this patch has to be ignored.
>
> In fact I wanted this patch to be approved first because without which
> sys call patch would not compile.


Why you cannot commit a patch list when the function is done?
I think the function in the trunk tree need be done before commit to
it.  If you want work in cvs, I suggest you use the branch first.

On the other hand, I heard that some of code of arm record is checked
in.  I don't think it is right.  Because without syscall support, it
cannot work, right?
So what I suggest is move all the code about arm record to a separate
branch.  And when all of the arm record function done, you re-send all
of them.

Thanks,
Hui



>
> Regards,
> Oza.
>
> On Mon, Jun 18, 2012 at 2:54 PM, Yao Qi <yao@codesourcery.com> wrote:
>> On 06/18/2012 05:08 PM, oza Pawandeep wrote:
>>> diff -urN orig/configure.tgt new/configure.tgt
>>> --- orig/configure.tgt        2012-06-18 12:36:47.274501400 +0530
>>> +++ new/configure.tgt 2012-06-18 12:31:47.335501400 +0530
>>> @@ -76,7 +76,7 @@
>>>  arm*-*-linux*)
>>>       # Target: ARM based machine running GNU/Linux
>>>       gdb_target_obs="arm-tdep.o arm-linux-tdep.o glibc-tdep.o \
>>> -                     solib-svr4.o symfile-mem.o linux-tdep.o"
>>> +                     solib-svr4.o symfile-mem.o linux-tdep.o linux-record.o"
>>>       build_gdbserver=yes
>>>       ;;
>>>  arm*-*-netbsd* | arm*-*-knetbsd*-gnu)
>>>
>>> ok to check in ?
>>
>> It is not good to post the same change twice in different mails.  This
>> change makes no sense until your 'arm-syscall record' patch is approved.
>>  I noticed that this change has been included in your 'arm-syscall
>> record' patch, so I think patch here doesn't have to reviewed.
>>
>> --
>> Yao (齐尧)
>>
>>

Re: [PATCH] Makefile.in includes linux-record.c to be common for all arch. (arm-reversible>phase-3)

[oza Pawandeep]

Hi Hui,

The phase2 works indepedently. It does not need syscall really. If i
recall correctly michael snyder suggested that i make two patches. The
first patch contains arm instructions and the second part contains
linux abi support.

The second part which i am working now requires linux-record.o hence i
wrote we require it to be compiled with the second part of patch.

So first i try to chek in minor change of configure.tgt and then i
check syscall record on arm; It has no dependency on any previous
arm-record stuffs.

By the way there is one more query which has been there under discussion.
When you made gdb sys call defination, it was thought as generic, but
it does not turn out to be applicable for arm as syscall number
differs. Sometime back tom had suggestion of having xml files under
gdb/syscalls  for arm arch and x86 separately; do you have any inputs
to it?  Of course it would change x86 syscall record to be read from
xml files.

Regards,
Oza.

On Tue, Jun 19, 2012 at 12:19 AM, oza Pawandeep <oza.pawandeep@gmail.com> wrote:
> Hi Hui,
>
> The phase2 works indepedently. It does not need syscall really. If i recall
> correctly michael snyder suggested that i make two patches.  The first patch
> contains arm instructions and the and second part contains linux abi
> support.
>
> The second part which i am working now requires linux-record.o hence i wrote
> we require it to be compiled with the second part of patch.
>
> So first i try to chek in minor change of congpfigure.tgt
> And then i check syscall record on arm.
>
> By the way there is one more query which has been there under discussion.
> When you made gdb sys call defination, it was thought as generic, but it
> does not turn out to be applicable for arm as syscall number differs.
> Sometime back tom had suggestion of having xml files under gdb/syscalls  for
> arm arch and x86 separately; do you have any inputs to it?  Of course it
> would change x86 syscall record to be read from xml files.j
>
> Regards,
> Oza.
>
> On Jun 18, 2012 2:22 PM, "Hui Zhu" <teawater@gmail.com> wrote:
>>
>> On Mon, Jun 18, 2012 at 7:49 PM, oza Pawandeep <oza.pawandeep@gmail.com>
>> wrote:
>> > Yes I agree; as I integrated both of them and post them at once.
>> > sorry about confusion; this patch has to be ignored.
>> >
>> > In fact I wanted this patch to be approved first because without which
>> > sys call patch would not compile.
>>
>>
>> Why you cannot commit a patch list when the function is done?
>> I think the function in the trunk tree need be done before commit to
>> it.  If you want work in cvs, I suggest you use the branch first.
>>
>> On the other hand, I heard that some of code of arm record is checked
>> in.  I don't think it is right.  Because without syscall support, it
>> cannot work, right?
>> So what I suggest is move all the code about arm record to a separate
>> branch.  And when all of the arm record function done, you re-send all
>> of them.
>>
>> Thanks,
>> Hui
>>
>>
>>
>> >
>> > Regards,
>> > Oza.
>> >
>> > On Mon, Jun 18, 2012 at 2:54 PM, Yao Qi <yao@codesourcery.com> wrote:
>> >> On 06/18/2012 05:08 PM, oza Pawandeep wrote:
>> >>> diff -urN orig/configure.tgt new/configure.tgt
>> >>> --- orig/configure.tgt        2012-06-18 12:36:47.274501400 +0530
>> >>> +++ new/configure.tgt 2012-06-18 12:31:47.335501400 +0530
>> >>> @@ -76,7 +76,7 @@
>> >>>  arm*-*-linux*)
>> >>>       # Target: ARM based machine running GNU/Linux
>> >>>       gdb_target_obs="arm-tdep.o arm-linux-tdep.o glibc-tdep.o \
>> >>> -                     solib-svr4.o symfile-mem.o linux-tdep.o"
>> >>> +                     solib-svr4.o symfile-mem.o linux-tdep.o
>> >>> linux-record.o"
>> >>>       build_gdbserver=yes
>> >>>       ;;
>> >>>  arm*-*-netbsd* | arm*-*-knetbsd*-gnu)
>> >>>
>> >>> ok to check in ?
>> >>
>> >> It is not good to post the same change twice in different mails.  This
>> >> change makes no sense until your 'arm-syscall record' patch is
>> >> approved.
>> >>  I noticed that this change has been included in your 'arm-syscall
>> >> record' patch, so I think patch here doesn't have to reviewed.
>> >>
>> >> --
>> >> Yao (齐尧)
>> >>
>> >>

Re: [PATCH] Makefile.in includes linux-record.c to be common for all arch. (arm-reversible>phase-3)

[Hui Zhu]

On Tue, Jun 19, 2012 at 2:49 AM, oza Pawandeep <oza.pawandeep@gmail.com> wrote:
> Hi Hui,
>
> The phase2 works indepedently. It does not need syscall really. If i recall
> correctly michael snyder suggested that i make two patches.  The first patch
> contains arm instructions and the and second part contains linux abi
> support.

I think he's means is divide the patch to insn part and syscall part.
But if you want to post to maillist or commit to cvs tree.  I think
they need to be commit together.
The reason is without the syscall-record support, how the patch test
with the testsuite?  Without that, How do you prove that your code is
correct?
For the x86-record code, the insn and syscall patch is commit
together.  So go back to my suggest, move all the code about arm
record to a separate branch.  And when you done all of them and past
the test, re-commit them.

>
> The second part which i am working now requires linux-record.o hence i wrote
> we require it to be compiled with the second part of patch.
>
> So first i try to chek in minor change of congpfigure.tgt
> And then i check syscall record on arm.
>
> By the way there is one more query which has been there under discussion.
> When you made gdb sys call defination, it was thought as generic, but it
> does not turn out to be applicable for arm as syscall number differs.
> Sometime back tom had suggestion of having xml files under gdb/syscalls  for
> arm arch and x86 separately; do you have any inputs to it?  Of course it
> would change x86 syscall record to be read from xml files.j

Do you really see the code of syscall-record part?  I suggest you
re-read the code.
The linux-syscall-record code can be work with most of the arch
because before call record_linux_system_call, the syscall number will
be translate to enum gdb_syscall.  You can see the
amd64_canonicalize_syscall as the example.

Thanks,
Hui

>
> Regards,
> Oza.
>
> On Jun 18, 2012 2:22 PM, "Hui Zhu" <teawater@gmail.com> wrote:
>>
>> On Mon, Jun 18, 2012 at 7:49 PM, oza Pawandeep <oza.pawandeep@gmail.com>
>> wrote:
>> > Yes I agree; as I integrated both of them and post them at once.
>> > sorry about confusion; this patch has to be ignored.
>> >
>> > In fact I wanted this patch to be approved first because without which
>> > sys call patch would not compile.
>>
>>
>> Why you cannot commit a patch list when the function is done?
>> I think the function in the trunk tree need be done before commit to
>> it.  If you want work in cvs, I suggest you use the branch first.
>>
>> On the other hand, I heard that some of code of arm record is checked
>> in.  I don't think it is right.  Because without syscall support, it
>> cannot work, right?
>> So what I suggest is move all the code about arm record to a separate
>> branch.  And when all of the arm record function done, you re-send all
>> of them.
>>
>> Thanks,
>> Hui
>>
>>
>>
>> >
>> > Regards,
>> > Oza.
>> >
>> > On Mon, Jun 18, 2012 at 2:54 PM, Yao Qi <yao@codesourcery.com> wrote:
>> >> On 06/18/2012 05:08 PM, oza Pawandeep wrote:
>> >>> diff -urN orig/configure.tgt new/configure.tgt
>> >>> --- orig/configure.tgt        2012-06-18 12:36:47.274501400 +0530
>> >>> +++ new/configure.tgt 2012-06-18 12:31:47.335501400 +0530
>> >>> @@ -76,7 +76,7 @@
>> >>>  arm*-*-linux*)
>> >>>       # Target: ARM based machine running GNU/Linux
>> >>>       gdb_target_obs="arm-tdep.o arm-linux-tdep.o glibc-tdep.o \
>> >>> -                     solib-svr4.o symfile-mem.o linux-tdep.o"
>> >>> +                     solib-svr4.o symfile-mem.o linux-tdep.o
>> >>> linux-record.o"
>> >>>       build_gdbserver=yes
>> >>>       ;;
>> >>>  arm*-*-netbsd* | arm*-*-knetbsd*-gnu)
>> >>>
>> >>> ok to check in ?
>> >>
>> >> It is not good to post the same change twice in different mails.  This
>> >> change makes no sense until your 'arm-syscall record' patch is
>> >> approved.
>> >>  I noticed that this change has been included in your 'arm-syscall
>> >> record' patch, so I think patch here doesn't have to reviewed.
>> >>
>> >> --
>> >> Yao (齐尧)
>> >>
>> >>

Re: [PATCH] Makefile.in includes linux-record.c to be common for all arch. (arm-reversible>phase-3)

[oza Pawandeep]

Let me elaborate it further how it works.

>   the bare metal insn is thought to be separately working; where it doesnt support syscall.

> now with this patch syscall support is provided; it is done in phases. I believe the change is huge and independent enough;

> this first patch has been in with the approval of Tom and it was under review for more than a year; I would have appreciated the early comments. the patch has been reviewed with all aspects. (of course I would expect some hiccups, that would be solved in due time)

> as far as syscall number is concerned; yes I have read the code and amd64_canonicalize_syscall. If you re-read the patch, arm_canonicalize_syscall is alredy defined, the question is not at internal gdb syscall number but at different level of conflicting syscall numbers.

please have a look at the chain
http://sources.redhat.com/ml/gdb/2012-05/msg00035.html

Regards,
Oza.

On Tue, Jun 19, 2012 at 7:04 AM, Hui Zhu <teawater@gmail.com> wrote:
> On Tue, Jun 19, 2012 at 2:49 AM, oza Pawandeep <oza.pawandeep@gmail.com> wrote:
>> Hi Hui,
>>
>> The phase2 works indepedently. It does not need syscall really. If i recall
>> correctly michael snyder suggested that i make two patches.  The first patch
>> contains arm instructions and the and second part contains linux abi
>> support.
>
> I think he's means is divide the patch to insn part and syscall part.
> But if you want to post to maillist or commit to cvs tree.  I think
> they need to be commit together.
> The reason is without the syscall-record support, how the patch test
> with the testsuite?  Without that, How do you prove that your code is
> correct?
> For the x86-record code, the insn and syscall patch is commit
> together.  So go back to my suggest, move all the code about arm
> record to a separate branch.  And when you done all of them and past
> the test, re-commit them.
>
>>
>> The second part which i am working now requires linux-record.o hence i wrote
>> we require it to be compiled with the second part of patch.
>>
>> So first i try to chek in minor change of congpfigure.tgt
>> And then i check syscall record on arm.
>>
>> By the way there is one more query which has been there under discussion.
>> When you made gdb sys call defination, it was thought as generic, but it
>> does not turn out to be applicable for arm as syscall number differs.
>> Sometime back tom had suggestion of having xml files under gdb/syscalls  for
>> arm arch and x86 separately; do you have any inputs to it?  Of course it
>> would change x86 syscall record to be read from xml files.j
>
> Do you really see the code of syscall-record part?  I suggest you
> re-read the code.
> The linux-syscall-record code can be work with most of the arch
> because before call record_linux_system_call, the syscall number will
> be translate to enum gdb_syscall.  You can see the
> amd64_canonicalize_syscall as the example.
>
> Thanks,
> Hui
>
>>
>> Regards,
>> Oza.
>>
>> On Jun 18, 2012 2:22 PM, "Hui Zhu" <teawater@gmail.com> wrote:
>>>
>>> On Mon, Jun 18, 2012 at 7:49 PM, oza Pawandeep <oza.pawandeep@gmail.com>
>>> wrote:
>>> > Yes I agree; as I integrated both of them and post them at once.
>>> > sorry about confusion; this patch has to be ignored.
>>> >
>>> > In fact I wanted this patch to be approved first because without which
>>> > sys call patch would not compile.
>>>
>>>
>>> Why you cannot commit a patch list when the function is done?
>>> I think the function in the trunk tree need be done before commit to
>>> it.  If you want work in cvs, I suggest you use the branch first.
>>>
>>> On the other hand, I heard that some of code of arm record is checked
>>> in.  I don't think it is right.  Because without syscall support, it
>>> cannot work, right?
>>> So what I suggest is move all the code about arm record to a separate
>>> branch.  And when all of the arm record function done, you re-send all
>>> of them.
>>>
>>> Thanks,
>>> Hui
>>>
>>>
>>>
>>> >
>>> > Regards,
>>> > Oza.
>>> >
>>> > On Mon, Jun 18, 2012 at 2:54 PM, Yao Qi <yao@codesourcery.com> wrote:
>>> >> On 06/18/2012 05:08 PM, oza Pawandeep wrote:
>>> >>> diff -urN orig/configure.tgt new/configure.tgt
>>> >>> --- orig/configure.tgt        2012-06-18 12:36:47.274501400 +0530
>>> >>> +++ new/configure.tgt 2012-06-18 12:31:47.335501400 +0530
>>> >>> @@ -76,7 +76,7 @@
>>> >>>  arm*-*-linux*)
>>> >>>       # Target: ARM based machine running GNU/Linux
>>> >>>       gdb_target_obs="arm-tdep.o arm-linux-tdep.o glibc-tdep.o \
>>> >>> -                     solib-svr4.o symfile-mem.o linux-tdep.o"
>>> >>> +                     solib-svr4.o symfile-mem.o linux-tdep.o
>>> >>> linux-record.o"
>>> >>>       build_gdbserver=yes
>>> >>>       ;;
>>> >>>  arm*-*-netbsd* | arm*-*-knetbsd*-gnu)
>>> >>>
>>> >>> ok to check in ?
>>> >>
>>> >> It is not good to post the same change twice in different mails.  This
>>> >> change makes no sense until your 'arm-syscall record' patch is
>>> >> approved.
>>> >>  I noticed that this change has been included in your 'arm-syscall
>>> >> record' patch, so I think patch here doesn't have to reviewed.
>>> >>
>>> >> --
>>> >> Yao (齐尧)
>>> >>
>>> >>

Re: [PATCH] Makefile.in includes linux-record.c to be common for all arch. (arm-reversible>phase-3)

[oza Pawandeep]

Hi Hui,

please ignore the syscall record patch;
I will be working on resolving certain things from gdb.reverse suite
on ARM for the first patch.

Regards,
Oza.



On Tue, Jun 19, 2012 at 10:43 AM, oza Pawandeep <oza.pawandeep@gmail.com> wrote:
> Let me elaborate it further how it works.
>
>>   the bare metal insn is thought to be separately working; where it doesnt support syscall.
>
>> now with this patch syscall support is provided; it is done in phases. I believe the change is huge and independent enough;
>
>> this first patch has been in with the approval of Tom and it was under review for more than a year; I would have appreciated the early comments. the patch has been reviewed with all aspects. (of course I would expect some hiccups, that would be solved in due time)
>
>> as far as syscall number is concerned; yes I have read the code and amd64_canonicalize_syscall. If you re-read the patch, arm_canonicalize_syscall is alredy defined, the question is not at internal gdb syscall number but at different level of conflicting syscall numbers.
>
> please have a look at the chain
> http://sources.redhat.com/ml/gdb/2012-05/msg00035.html
>
> Regards,
> Oza.
>
> On Tue, Jun 19, 2012 at 7:04 AM, Hui Zhu <teawater@gmail.com> wrote:
>> On Tue, Jun 19, 2012 at 2:49 AM, oza Pawandeep <oza.pawandeep@gmail.com> wrote:
>>> Hi Hui,
>>>
>>> The phase2 works indepedently. It does not need syscall really. If i recall
>>> correctly michael snyder suggested that i make two patches.  The first patch
>>> contains arm instructions and the and second part contains linux abi
>>> support.
>>
>> I think he's means is divide the patch to insn part and syscall part.
>> But if you want to post to maillist or commit to cvs tree.  I think
>> they need to be commit together.
>> The reason is without the syscall-record support, how the patch test
>> with the testsuite?  Without that, How do you prove that your code is
>> correct?
>> For the x86-record code, the insn and syscall patch is commit
>> together.  So go back to my suggest, move all the code about arm
>> record to a separate branch.  And when you done all of them and past
>> the test, re-commit them.
>>
>>>
>>> The second part which i am working now requires linux-record.o hence i wrote
>>> we require it to be compiled with the second part of patch.
>>>
>>> So first i try to chek in minor change of congpfigure.tgt
>>> And then i check syscall record on arm.
>>>
>>> By the way there is one more query which has been there under discussion.
>>> When you made gdb sys call defination, it was thought as generic, but it
>>> does not turn out to be applicable for arm as syscall number differs.
>>> Sometime back tom had suggestion of having xml files under gdb/syscalls  for
>>> arm arch and x86 separately; do you have any inputs to it?  Of course it
>>> would change x86 syscall record to be read from xml files.j
>>
>> Do you really see the code of syscall-record part?  I suggest you
>> re-read the code.
>> The linux-syscall-record code can be work with most of the arch
>> because before call record_linux_system_call, the syscall number will
>> be translate to enum gdb_syscall.  You can see the
>> amd64_canonicalize_syscall as the example.
>>
>> Thanks,
>> Hui
>>
>>>
>>> Regards,
>>> Oza.
>>>
>>> On Jun 18, 2012 2:22 PM, "Hui Zhu" <teawater@gmail.com> wrote:
>>>>
>>>> On Mon, Jun 18, 2012 at 7:49 PM, oza Pawandeep <oza.pawandeep@gmail.com>
>>>> wrote:
>>>> > Yes I agree; as I integrated both of them and post them at once.
>>>> > sorry about confusion; this patch has to be ignored.
>>>> >
>>>> > In fact I wanted this patch to be approved first because without which
>>>> > sys call patch would not compile.
>>>>
>>>>
>>>> Why you cannot commit a patch list when the function is done?
>>>> I think the function in the trunk tree need be done before commit to
>>>> it.  If you want work in cvs, I suggest you use the branch first.
>>>>
>>>> On the other hand, I heard that some of code of arm record is checked
>>>> in.  I don't think it is right.  Because without syscall support, it
>>>> cannot work, right?
>>>> So what I suggest is move all the code about arm record to a separate
>>>> branch.  And when all of the arm record function done, you re-send all
>>>> of them.
>>>>
>>>> Thanks,
>>>> Hui
>>>>
>>>>
>>>>
>>>> >
>>>> > Regards,
>>>> > Oza.
>>>> >
>>>> > On Mon, Jun 18, 2012 at 2:54 PM, Yao Qi <yao@codesourcery.com> wrote:
>>>> >> On 06/18/2012 05:08 PM, oza Pawandeep wrote:
>>>> >>> diff -urN orig/configure.tgt new/configure.tgt
>>>> >>> --- orig/configure.tgt        2012-06-18 12:36:47.274501400 +0530
>>>> >>> +++ new/configure.tgt 2012-06-18 12:31:47.335501400 +0530
>>>> >>> @@ -76,7 +76,7 @@
>>>> >>>  arm*-*-linux*)
>>>> >>>       # Target: ARM based machine running GNU/Linux
>>>> >>>       gdb_target_obs="arm-tdep.o arm-linux-tdep.o glibc-tdep.o \
>>>> >>> -                     solib-svr4.o symfile-mem.o linux-tdep.o"
>>>> >>> +                     solib-svr4.o symfile-mem.o linux-tdep.o
>>>> >>> linux-record.o"
>>>> >>>       build_gdbserver=yes
>>>> >>>       ;;
>>>> >>>  arm*-*-netbsd* | arm*-*-knetbsd*-gnu)
>>>> >>>
>>>> >>> ok to check in ?
>>>> >>
>>>> >> It is not good to post the same change twice in different mails.  This
>>>> >> change makes no sense until your 'arm-syscall record' patch is
>>>> >> approved.
>>>> >>  I noticed that this change has been included in your 'arm-syscall
>>>> >> record' patch, so I think patch here doesn't have to reviewed.
>>>> >>
>>>> >> --
>>>> >> Yao (齐尧)
>>>> >>
>>>> >>