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

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

[Tom Tromey]

>>>>> "oza" == oza Pawandeep <oza.pawandeep@gmail.com> writes:

oza> currently linux-record.h is having defination of
oza> enum gdb_syscall {...} which seems generic one, but infact it only
oza> addresses i386 arch.

Based on reading the header, it seems to me that the idea is that this
enum is intended to be generic, and that each target must provide its
own mapping from the local syscalls to these.

oza> I am thinking of moving all the definition to i386 specific files
oza> (assuming there is no generic way to address all the systemcalls on
oza> all arch).

It seems to me that most syscalls could perhaps be shared, but maybe
some architectures will require additions to the enum.

I'm not sure, though.

Could you say in more detail what problem you ran into?

Tom

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

[oza Pawandeep]

Tom,

The definition of system call record maps fine to x86.
but arm syscall numbers are different. [partially]
for e.g. on x86 sycall number for sys_epoll_create = 254 while on ARM it is 250.
the more we go down on defined system calls the more the numbers are
differing on ARM and we loose one to one trivial mapping.

Regards,
Oza.

On Thu, May 10, 2012 at 2:08 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "oza" == oza Pawandeep <oza.pawandeep@gmail.com> writes:
>
> oza> currently linux-record.h is having defination of
> oza> enum gdb_syscall {...} which seems generic one, but infact it only
> oza> addresses i386 arch.
>
> Based on reading the header, it seems to me that the idea is that this
> enum is intended to be generic, and that each target must provide its
> own mapping from the local syscalls to these.
>
> oza> I am thinking of moving all the definition to i386 specific files
> oza> (assuming there is no generic way to address all the systemcalls on
> oza> all arch).
>
> It seems to me that most syscalls could perhaps be shared, but maybe
> some architectures will require additions to the enum.
>
> I'm not sure, though.
>
> Could you say in more detail what problem you ran into?
>
> Tom

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

[Tom Tromey]

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

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

[oza Pawandeep]

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

Re: [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

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

[oza Pawandeep]

following are the ARM syscalls.

/* 270 */    CALL(sys_arm_fadvise64_64)
                CALL(sys_pciconfig_iobase)
                CALL(sys_pciconfig_read)
                CALL(sys_pciconfig_write)
                CALL(sys_mq_open)

linux-record.h has a conflict at slot 271, 272 an so on..
sys_pciconfig_iobase is not defined at all.
It is confusing where to define in the enum gdb_syscall table.

current code looks like this...

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

  if (syscall <= arm_sys_prlimit64)
    {
      if (syscall <= gdb_sys_sched_getaffinity)
        return syscall;
      else if (syscall <= gdb_sys_fadvise64_64)
        {
          return (syscall + (unsigned int)2);
        }
      else
        {
          switch (syscall)
            {

            }
        }
    }
  else
    return -1;
}

It becomes clumsy as we start adding some more syscalls in the generic
structure. (even If we are able to find slots).

Regards,
Oza.


On Sun, May 13, 2012 at 1:03 PM, oza Pawandeep <oza.pawandeep@gmail.com> wrote:
> 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

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

[Joel Brobecker]

> static enum gdb_syscall
> arm_canonicalize_syscall (int syscall)
> {
>   enum { arm_sys_prlimit64 = 369 };
> 
>   if (syscall <= arm_sys_prlimit64)
>     {
>       if (syscall <= gdb_sys_sched_getaffinity)
>         return syscall;
>       else if (syscall <= gdb_sys_fadvise64_64)
>         {
>           return (syscall + (unsigned int)2);
>         }
>       else
>         {
>           switch (syscall)

Why not define a table that defines the mapping for every syscall?
We do that for registers -vs- register names, for instance, and that
works very well.

    static enum gdb_syscall arm_syscal_map[] =
    {
      gdb_sys_restart_syscall, gdb_sys_exit, gdb_sys_fork,
      [...]
      gdb_sys_sched_getaffinity, gdb_sys_arm_trap16,
      [...]
    };

-- 
Joel

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

[oza Pawandeep]

I would have liked to think the same; but the way linux-record.h
addresses all the architecture, the enum sycall, is defiend
generically.

what I think is define it in arch files, as syscalls are partially
dependent on arch, though they follow posix standard.

so each arch file would have their own map, compare to current generic
map in linux-record.h

Regards,
Oza.

On Mon, May 14, 2012 at 8:26 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>> static enum gdb_syscall
>> arm_canonicalize_syscall (int syscall)
>> {
>>   enum { arm_sys_prlimit64 = 369 };
>>
>>   if (syscall <= arm_sys_prlimit64)
>>     {
>>       if (syscall <= gdb_sys_sched_getaffinity)
>>         return syscall;
>>       else if (syscall <= gdb_sys_fadvise64_64)
>>         {
>>           return (syscall + (unsigned int)2);
>>         }
>>       else
>>         {
>>           switch (syscall)
>
> Why not define a table that defines the mapping for every syscall?
> We do that for registers -vs- register names, for instance, and that
> works very well.
>
>    static enum gdb_syscall arm_syscal_map[] =
>    {
>      gdb_sys_restart_syscall, gdb_sys_exit, gdb_sys_fork,
>      [...]
>      gdb_sys_sched_getaffinity, gdb_sys_arm_trap16,
>      [...]
>    };
>
> --
> Joel

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

[Joel Brobecker]

> so each arch file would have their own map, compare to current generic
> map in linux-record.h

If I understand what you are saying correctly, I think that this is
what I had in mind.

NB: I should point out that I have little knowledge of the process-
record code. Just trying to help out with possible solutions if
we think the best option is to have one generic enum.

-- 
Joel

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

[Tom Tromey]

>>>>> "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

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

[oza Pawandeep]

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

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

[Tom Tromey]

>>>>> "oza" == oza Pawandeep <oza.pawandeep@gmail.com> writes:

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

The idea is to extend the current approach.  That is, have a single
generic enum; then map the system-specific numbers to this enum.  The
difference is that the mappings would be generated from the XML files.

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

Yeah, I don't like this much.

Tom

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

[oza Pawandeep]

I have gone through some of the xml stuffs already done.
under gdb/syscalls/arch_linux.xml files exist. which is currently not
used for record-purpose.

there are 2 ways we could go ahead now:

1) use the above file for recording purpose too and define new
arm-linux.xml for arm specific syscalls.

2) or we decide to keep only one combined xml files for record-replay
future for all arch.

PS: syscall code is almost done now, it supports 242 syscalls
[till gdb_sys_sched_getaffinity = 242]

(xml stuff is pending)


Regards,
Oza.

On Wed, May 16, 2012 at 8:26 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "oza" == oza Pawandeep <oza.pawandeep@gmail.com> writes:
>
> oza> b) I am not much familiar with xml generated C files, and where to
> oza> change in gdb, but with that, will the record_linux_system_call be
> oza> able to incorporate all conflicting syscall numbers in that case ?
>
> The idea is to extend the current approach.  That is, have a single
> generic enum; then map the system-specific numbers to this enum.  The
> difference is that the mappings would be generated from the XML files.
>
> oza> define as follows
> oza> enum gdb_syscall
> oza> {
> oza>            /* i386 related syscalls */
> oza>            /* ARM related syscalls */
> oza>            /* MIPS related syscalls */
> oza>            so on..
> oza> }
>
> Yeah, I don't like this much.
>
> Tom

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

[Tom Tromey]

>>>>> "Oza" == oza Pawandeep <oza.pawandeep@gmail.com> writes:

Oza> 1) use the above file for recording purpose too and define new
Oza> arm-linux.xml for arm specific syscalls.

Oza> 2) or we decide to keep only one combined xml files for record-replay
Oza> future for all arch.

I think separate files is best.

If there is substantial commonality, we can do inclusions, the way that
is done in some features/*.xml files.  E.g, from
features/arm-with-m.xml:

    <!DOCTYPE target SYSTEM "gdb-target.dtd">
    <target>
      <xi:include href="arm-m-profile.xml"/>
    </target>

Tom

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

[oza Pawandeep]

I have gone through some of the xml stuffs already done.
under gdb/syscalls/arch_linux.xml files exist. which is currently not
used for record-purpose.

there are 2 ways we could go ahead now:

1) use the above file for recording purpose too and define new
arm-linux.xml for arm specific syscalls.

2) or we decide to keep only one combined xml files for record-replay
future for all arch.

PS: syscall code is almost done now, it supports 242 syscalls
[till gdb_sys_sched_getaffinity = 242]

(xml stuff is pending, for which either approach 1) or 2) could be taken.)

Regards,
Oza.

On Wed, May 16, 2012 at 8:26 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "oza" == oza Pawandeep <oza.pawandeep@gmail.com> writes:
>
> oza> b) I am not much familiar with xml generated C files, and where to
> oza> change in gdb, but with that, will the record_linux_system_call be
> oza> able to incorporate all conflicting syscall numbers in that case ?
>
> The idea is to extend the current approach.  That is, have a single
> generic enum; then map the system-specific numbers to this enum.  The
> difference is that the mappings would be generated from the XML files.
>
> oza> define as follows
> oza> enum gdb_syscall
> oza> {
> oza>            /* i386 related syscalls */
> oza>            /* ARM related syscalls */
> oza>            /* MIPS related syscalls */
> oza>            so on..
> oza> }
>
> Yeah, I don't like this much.
>
> Tom

[design change] record-replay linux ABI level

[oza Pawandeep]

Hi all,

currently linux-record.h is having defination of
enum gdb_syscall {...} which seems generic one, but infact it only
addresses i386 arch.

the way the arm syscall number defined are different and mapping is different.

I am thinking of moving all the definition to i386 specific files
(assuming there is no generic way to address all the systemcalls on
all arch).

there might be similar instances which also like to be moved to i386
specific file
(for e.g. struct linux_record_tdep
{
  /* The size of the type that will be used in a system call.  */
  int size_pointer;
  int size__old_kernel_stat;
  int size_tms;
-
-
-
-
-
}

please let me know any input for the same, as I am working on arm
syscall recording part.

Regards,
Oza.