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

[teawater <teawater at gmail dot com>]

The new comment for record_linux_system_call is:
/* When the architecture process record get a Linux syscall instruction, it
   will get a Linux syscall number of this architecture and convert it to the
   Linux syscall number "num" which is internal to GDB.
   Most Linux syscalls across architectures in Linux would be similar and
   mostly differ by sizes of types and structures.  This sizes are put
   to "tdep".
   Record the values of the registers and memory that will be changed in
   current system call.
   Return -1 if something wrong.  */

Thanks,
Hui

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.
>
> 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?
>
> 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).
>
> 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.
>
>> > 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.
>
>> Put it to xml file it's been talk in
>> "http://sourceware.org/ml/gdb-patches/2008-11/msg00171.html";.
>> What about do it later?
>
> Yes, it makes sense to me.
> --
> []'s
> Thiago Jung Bauermann
> IBM Linux Technology Center
>
>