Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: oza Pawandeep <oza.pawandeep@gmail.com>
To: Hui Zhu <teawater@gmail.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	Yao Qi <yao@codesourcery.com>
Subject: Re: [PATCH] Makefile.in includes linux-record.c to be common for all arch. (arm-reversible>phase-3)
Date: Tue, 19 Jun 2012 16:03:00 -0000	[thread overview]
Message-ID: <CAK1A=4w6y7-ZXrooYL8GnjVdjFud1cNhMwbS7pTOMPg5itgz1w@mail.gmail.com> (raw)
In-Reply-To: <CAK1A=4wDcT9vBMZKDp36WmL6oGt7CmZQWNAOS6mYne0rwOustg@mail.gmail.com>

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 (齐尧)
>>>> >>
>>>> >>


      reply	other threads:[~2012-06-19 16:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-07  3:51 oza Pawandeep
2012-06-07 13:41 ` Yao Qi
2012-06-07 17:20   ` oza Pawandeep
2012-06-08  6:09     ` Matt Rice
2012-06-08 12:45       ` oza Pawandeep
2012-06-18  9:08         ` oza Pawandeep
2012-06-18  9:24           ` Yao Qi
2012-06-18 11:49             ` oza Pawandeep
2012-06-18 14:22               ` Hui Zhu
     [not found]                 ` <CAK1A=4wdqiGCGGQuQHmDB19O=RfjttaG9M83KpBkuUyQPd=0qQ@mail.gmail.com>
2012-06-18 18:55                   ` oza Pawandeep
2012-06-19  1:35                   ` Hui Zhu
2012-06-19  5:13                     ` oza Pawandeep
2012-06-19 16:03                       ` oza Pawandeep [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAK1A=4w6y7-ZXrooYL8GnjVdjFud1cNhMwbS7pTOMPg5itgz1w@mail.gmail.com' \
    --to=oza.pawandeep@gmail.com \
    --cc=gdb-patches@sourceware.org \
    --cc=teawater@gmail.com \
    --cc=yao@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox