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

[teawater <teawater@gmail.com>]

Hi Thiago,

Sorry to disturb you.
Could you help me on http://sourceware.org/ml/gdb-patches/2008-11/msg00536.html

Thanks,
Hui

On Thu, Nov 20, 2008 at 16:45, teawater <teawater@gmail.com> wrote:
> According to your mail. I think maybe you didn't get my answer. And I
> am sorry that send "[RFA] Resubmit" without get you answer.
>
> http://sourceware.org/ml/gdb-patches/2008-11/msg00310.html
> Following is the content of the answer:
> Thanks Thiago.
> On Fri, Nov 14, 2008 at 03:56, Thiago Jung Bauermann
> <bauerman@br.ibm.com> wrote:
>> El jue, 06-11-2008 a las 15:48 +0800, teawater escribió:
>>> +/* Record the values of the registers and memory that will be changed in
>>> +   current system call.
>>> +   Return -1 if something wrong.  */
>>> +
>>> +int
>>> +record_linux_system_call (int num, linux_record_tdep_t * tdep)
>>> +{
>>> +  uint32_t tmpu32;
>>> +
>>> +  switch (num)
>>> +    {
>> <snip>
>>> +      /* sys_read */
>>> +    case 3:
>>> +      {
>>> +     uint32_t addr, count;
>>> +     regcache_raw_read (record_regcache, tdep->arg2, (gdb_byte *) & addr);
>>> +     regcache_raw_read (record_regcache, tdep->arg3, (gdb_byte *) & count);
>>> +     if (record_arch_list_add_mem (addr, count))
>>> +       {
>>> +         return (-1);
>>> +       }
>>> +      }
>>> +      break;
>> <snip>
>>> +    case 84:
>>> +      regcache_raw_read (record_regcache, tdep->arg2, (gdb_byte *) & tmpu32);
>>> +      if (record_arch_list_add_mem (tmpu32, tdep->size__old_kernel_stat))
>>> +     {
>>> +       return (-1);
>>> +     }
>>> +      break;
>>
>> 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.
>
>
>
>
>>
>> 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".
>
> 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?
>
>
> Hui
>
>
> On Thu, Nov 20, 2008 at 12:00, Thiago Jung Bauermann
> <bauerman@br.ibm.com> wrote:
>> El mié, 19-11-2008 a las 17:49 -0800, Michael Snyder escribió:
>>> Thiago, you had a question about whether the syscall id numbers
>>> were invariant across architectures, and I think Hui answered that
>>> he was using the i386 numbering as representative, and would use
>>> a target-specific header file or something to translate them.
>>>
>>> Or something to that effect.
>>>
>>> Did that answer your concern?
>>
>> I had two different but related concerns, regarding this 5th patch:
>>
>> 1. linux-record.c is really i386 specific, so it should be called
>> i386-linux-record.c.
>>
>> 2. If the information that needs to be recorded for each syscall (not
>> the syscall number) is the same accross architectures, the code in
>> linux-record.c could be made arch-independent and then we wouldn't need
>> to have this big chunk of code duplicated for each arch supporting
>> record functionality.
>>
>> I'm fine with leaving 2 to be investigated/addressed when record adds
>> support for its 2nd arch. It also may prove impractical, since there may
>> be slight differences in syscalls for each arch.
>> --
>> []'s
>> Thiago Jung Bauermann
>> IBM Linux Technology Center
>>
>>
>