Re: Compat 32-bit syscall entry from 64-bit task!?

[Denys Vlasenko <vda.linux@googlemail.com>]

On Thursday 26 January 2012 01:40, Indan Zupancic wrote:
> >> We can add the new events,
> >>
> >> 	PTRACE_EVENT_SYSCALL_ENTRY
> >> 	PTRACE_EVENT_SYSCALL_COMPAT_ENTRY
> >> 	PTRACE_EVENT_SYSCALL_EXIT
> >> 	PTRACE_EVENT_SYSCALL_COMPAT_EXIT
> >
> > We can get away with just the first one.
> > (1) It's unlikely people would want to get native sysentry events but not compat ones,
> > thus first two options can be combined into one;
> 
> True.
> 
> > (2) syscall exit compat-ness is known from entry type - no need to indicate it; and
> > (3) if we would flag syscall entry with an event value in wait status, then syscall
> > exit will be already distinquisable.
> 
> False for execve which messes everything up by changing TID sometimes.

Dealt with in Linus tree already: set PTRACE_O_TRACEEXEC option,
and use PTRACE_GETEVENTMSG in PTRACE_EVENT_EXEC stop to get
the old TID.


> > To future-proof this scheme we may reserve a few more event values
> > PTRACE_EVENT_SYSCALL_ENTRY2, PTRACE_EVENT_SYSCALL_ENTRY3, etc,
> > if we'll ever have arches with more than one non-native syscall
> > entry. I'm no expert, but looking at strace code, ARM may already have
> > more than one additional convention how to pass syscall args.
> 
> Please, no! This way lays madness, just one PTRACE_EVENT_SYSCALL_ENTRY,
> no PTRACE_EVENT_SYSCALL_ENTRY1 or PTRACE_EVENT_SYSCALL_ENTRY2, that
> would be horrible. Keep arch specific stuff in arch specific areas,
> please don't spread it around.

The situation when an architecture has 32- and 64-bit varieties,
and sometimes different ABIs (parameter passing comventions),
is rather typical, it's not a quirk of just one unfortunate
architecture.

Please look at strace source, get_scno() function, where
it reads syscall no and parameters. Let's see....
- POWERPC: has 32-bit and 64-bit mode
- X86_64: has 32-bit and 64-bit mode
- IA64: has i386-compat mode
- ARM: has more than one ABI
- SPARC: has 32-bit and 64-bit mode

Do you want to re-invent a different arch-specific way to report
syscall type for each of these arches?


> What was wrong with using eflags again? Is it too simple or something?

It's x86-specific, and abuses a bit in a real register.

-- 
vda