This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [design change] record-replay linux ABI level


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]