[PATCH v2 0/2] Introduce asinfo tool

[Dmitry V. Levin]

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" <ldv at 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" <ldv at 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.

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?


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20170728/db22a56c/attachment.bin>