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

[oza Pawandeep <oza.pawandeep@gmail.com>]

Tom,

a) yes; The record_linux_system_call is a problem because the
conflicting number would conflict in
{switch} {case} construct of the functions.

b) I am not much familiar with xml generated C files, and where to
change in gdb, but with that, will the record_linux_system_call be
able to incorporate all conflicting syscall numbers in that case ?

c)  there is another way, which is align to current design. (it is not
very very clean but manageable)

define as follows
enum gdb_syscall
{
           /* i386 related syscalls */
           /* ARM related syscalls */
           /* MIPS related syscalls */
           so on..
}

if syscalls share the same number then it is one-to-one mapping.
if at the same number, syscalls are different then add them under ARM
number which would start just after i386.
if there are common syscalls but different number then there would be
shift by a number. then it has to be adjusted in function

static enum gdb_arm_syscall
arm_canonicalize_syscall (int syscall)
{
  enum { arm_sys_prlimit64 = 369 };

  if (syscall <= arm_sys_prlimit64)
    return syscall;
  else
    return -1;
}

Regards,
Oza.


On Tue, May 15, 2012 at 10:11 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Oza" == oza Pawandeep <oza.pawandeep@gmail.com> writes:
>
> Oza> I would have liked to think the same; but the way linux-record.h
> Oza> addresses all the architecture, the enum sycall, is defiend
> Oza> generically.
>
> Oza> what I think is define it in arch files, as syscalls are partially
> Oza> dependent on arch, though they follow posix standard.
>
> Oza> so each arch file would have their own map, compare to current generic
> Oza> map in linux-record.h
>
> If it really makes things better, it is fine by me.
>
> What do you propose to do with record_linux_system_call?
>
>
> How about another approach?  Keep the current mapping idea, but extract
> the mappings from syscalls/*.xml.  That way we help out two features
> with a single data file.
>
> Tom