[design change] record-replay linux ABI level

[oza Pawandeep]

what I would do is, I will go ahead with curernt defination of enum.
and try to provide mapping.
if there are practical conflicts then I would seek for alternatives.

Regards,
Oza.

On Sun, May 13, 2012 at 12:49 PM, oza Pawandeep <oza.pawandeep@gmail.com> wrote:
> currently on i386 following is the function:
>
> static enum gdb_syscall
> i386_canonicalize_syscall (int syscall)
> {
>  enum { i386_syscall_max = 499 };
>
>  if (syscall <= i386_syscall_max)
>    return syscall;
>  else
>    return -1;
> }
>
> which is just straight mapping.
>
> If we use generic enum defination, we will end up adding some
> additional syscalls for ARM and
>
> arm_canonicalize_syscall(int syscall)
> end up having switch {case} and having one-to one mapping for some
> syscalls and rest syscalls would be shift by 'n' position.
> which looks clumsy to me.
>
>
> I am trying to see if there is more generic way which would take care
> of all archor move the defination to arch files.
> will try to see what best could be done.
>
> Regards,
> Oza.
>
>
>
> On Thu, May 10, 2012 at 7:09 PM, Tom Tromey <tromey@redhat.com> wrote:
>> Oza> The definition of system call record maps fine to x86.  but arm
>> Oza> syscall numbers are different. [partially] for e.g. on x86 sycall
>> Oza> number for sys_epoll_create = 254 while on ARM it is 250.  the more
>> Oza> we go down on defined system calls the more the numbers are
>> Oza> differing on ARM and we loose one to one trivial mapping.
>>
>> My understanding of the current design is that the ARM code would see
>> the syscall 250, and have a mapping to turn that into
>> gdb_sys_epoll_create (== 254).  This can be done bidirectionally with
>> two lookup tables.
>>
>> I suppose this could still not work in some scenarios.  One question is
>> whether these occur in practice or are merely theoretical.
>>
>> I don't really care about this API either way.
>> With a solid justification it is fine to change it.
>>
>> Tom