On Fri, 28 Jul 2017 15:50:39 +0300 "Dmitry V. Levin" <l...@altlinux.org> wrote:
> On Fri, Jul 28, 2017 at 03:01:19PM +0300, Edgar Kaziakhmedov wrote:
> > On Fri, 28 Jul 2017 14:53:23 +0300
> > "Dmitry V. Levin" <l...@altlinux.org> wrote:
> >
> > > On Fri, Jul 28, 2017 at 02:47:23PM +0300, Edgar Kaziakhmedov
> > > wrote:
> > > > On Fri, 28 Jul 2017 13:26:41 +0300
> > > > "Dmitry V. Levin" <l...@altlinux.org> wrote:
> > > >
> > > > > On Fri, Jul 28, 2017 at 08:33:57AM +0300, Edgar Kaziakhmedov
> > > > > wrote: [...]
> > > > > > Actually, I am not quite sure about ARM architectures, am I
> > > > > > right there or not. (I mean ABI modes). Because, according
> > > > > > to the current syscallent.h file in arm dir, there is not
> > > > > > support for subcall in ARM EABI, is it correct? Because, in
> > > > > > the kernel there is place for these subcalls.
> > > > >
> > > > > That's simple. If you have a look at the kernel, you'll see
> > > > > the following:
> > > > >
> > > > > $ grep -Fw oabi arch/arm/tools/syscall.tbl
> > > > > # <num> <abi> <name>
> > > > > [<entry
> > > > > point> [<oabi compat entry point>]] #
> > > > > point> common
> > > > > point> - for system calls shared between oabi and eabi
> > > > > point> (may have compat)
> > > > > # oabi - for oabi-only system calls (may have compat)
> > > > > # For each syscall number, "common" is mutually exclusive with
> > > > > oabi and eabi 13 oabi time
> > > > > sys_time 22 oabi umount
> > > > > sys_oldumount 25 oabi stime
> > > > > sys_stime 27 oabi alarm
> > > > > sys_alarm 30 oabi utime
> > > > > sys_utime 76 oabi getrlimit
> > > > > sys_old_getrlimit 82 oabi
> > > > > select sys_old_select 89
> > > > > oabi readdir sys_old_readdir
> > > > > 90 oabi mmap sys_old_mmap
> > > > > 102 oabi socketcall sys_socketcall
> > > > > sys_oabi_socketcall 113 oabi
> > > > > syscall sys_syscall 117 oabi
> > > > > ipc sys_ipc sys_oabi_ipc
> > > > >
> > > > > In other words, socketcall and ipc are implemented for oabi
> > > > > only, on eabi they return ENOSYS.
> > > >
> > > > Yes, sure, however, am I right, that syscallent.h will be the
> > > > same in sense of first 398 syscalls for ARM OABI and for ARM
> > > > EABI? I'd say, that it'd be convinient to add #ifdef directive
> > > > to syscalls, that are purposed for just OABI mode, and in case
> > > > of EABI fill them as zero.
> > >
> > > Why do you think it would be more convenient if, say, ipc syscall
> > > called on arm eabi would be printed as "syscall_117" rather than
> > > "ipc"?
> >
> > It would be convinient in sense of understanding of the syscallent.h
> > file, for example, in mips architecture you separated syscall files
> > into syscall-compat.h, syscall-o32h, syscall-o32-stub.h etc
> >
> > When strace compiled on mips with N32 ABI mode,
> > syscall-o32.h will be included with the following syscalls
> > [4000] = { MA, 0, SEN(printargs),
> > "o32:syscall" }, /* start of Linux o32 */ instead of
> > [4000] = { MA, 0,
> > SEN(syscall), "syscall" }, /*
> > start of Linux o32 */ And in this sense, I think I'd make the same
> > principle with the ARM architecture.
>
> On mips, each abi has its own interval of syscall numbers, so you
> cannot just print, say, "open" for o32, n32, and n64 without causing
> confusion.
>
> On arm, the numbers are shared between oabi and eabi, and, unlike
> mips, you cannot have oabi and eabi in the kernel simultaneously, so
> there is no confusion and "ipc" is just "ipc", not "oabi:ipc" or
> "eabi:ipc", although ipc on arm eabi always returns ENOSYS.
>
> Do you still want to make oabi-only syscalls printed with "oabi:"
> prefix on arm eabi?
>
>
So, that's it. But as I understood when we are speaking about
implemented syscalls for the ARM EABI, it means that we shouldn't take
into consideration OABI syscalls, like ipc, socketcall etc, am I right?
pgpmbe5CHodXP.pgp
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
