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 (may
> > > point>    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.

Attachment: pgp8yRdd_EK6Y.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

Reply via email to