Re: [RFA] Process record and replay, 5/10

[teawater <teawater@gmail.com>]

Thanks Thiago,

On Wed, Dec 3, 2008 at 09:33, Thiago Jung Bauermann <bauerman@br.ibm.com> wrote:
> Hi teawater,
>
> Sorry for the big delay in my response.

Never mind.  :)

>
> El vie, 14-11-2008 a las 16:36 +0800, teawater escribió:
>> On Fri, Nov 14, 2008 at 03:56, Thiago Jung Bauermann
>> <bauerman@br.ibm.com> wrote:
>> > Syscalls have different numbers across different architectures in Linux,
>> > so this file should be named i386-linux-record.c.
>>
>> This number is same with i386 number. It's friendly to other arch.
>>
>> Let me do a introduce of it.
>> When a record get a system call. It will get the the system number
>> with itself and convert it to the number that you found in
>> linux-record.c. I think it can use a table or something like it to
>> make covert speed up.
>> There is not some limit of this number. So I make it same with I386.
>
> So are you saying that record_linux_system_call takes a syscall number
> which is internal to GDB and doesn't necessarily correspond to the
> syscall numbers used in the target?
>
Yes.


> Right now there's only the i386 implementation of record, so the
> internal implementation is equivalent to it (and indeed,
> i386_linux_intx80_sysenter_record takes the syscall number from the
> register and passes it to record_linux_system_call).

Yes, that is what it does.

>
> If that is the case, then I'm ok. But a comment in
> record_linux_system_call explaining this intended use would help someone
> wanting to add record support to a new architecture.

OK.  I will.

>
>> > Do you know if what you need to record for a syscall in one architecture
>> > is the same as what you need to record in the others? If so, it wouldn't
>> > be hard to make this file general for Linux in all architectures, and
>> > just get the syscall number mapping from the XML in the catch syscall
>> > feature (here are we talking about it again... :-) ). Otherwise, you'll
>> > have to rename the file, and also you can't directly call
>> > record_linux_system_call directly from i386-linux-tdep.c like you do
>> > now. You'd have to add a gdbarch method and reach this code through
>> > that.
>>
>> I think most of system call in each arch are same. Except the size of
>> variables is not same. So I let arch set the size to argv "tdep" of
>> record_linux_system_call.
>>
>> And if some system call of a arch is not same with others. It can deal
>> with it in code of itself. For example, If i386 have a special system
>> call that not same with other arch. It can deal with it in function
>> "i386_linux_intx80_sysenter_record".
>
> I like this idea. I don't have any authority or experience to make
> recommendations about this, but I'd guess that like you say, most
> syscalls across architectures in Linux would be similar and mostly
> differ by sizes of types and structures. If exceptions to this rule can
> be dealt with separately, than most of the laborious syscall-recording
> work can be reused in record_linux_system_call. Sounds great, thanks for
> the explanation.
>
> If you could mention this intention of reusing this function for other
> architectures, that would tip someone wanting to port record to another
> architecture, IMHO.

Yes, that is what I try to do.
Thanks for your explain.  That is much better than me.  I will add
them to comments if you don't mind.  :)


Hui