On 6/13/19 4:00 PM, Paul Clarke wrote: > On 6/12/19 1:32 AM, Naveen N. Rao wrote: >> Paul Clarke wrote: >>> What are the circumstances in which raw_syscalls:sys_exit reports "-1" for >>> the syscall ID? >>> >>> perf 5375 [007] 59632.478528: raw_syscalls:sys_enter: NR 1 (3, >>> 9fb888, 8, 2d83740, 1, 7ffff) >>> perf 5375 [007] 59632.478532: raw_syscalls:sys_exit: NR 1 = 8 >>> perf 5375 [007] 59632.478538: raw_syscalls:sys_enter: NR 15 (11, >>> 7ffffca734b0, 7ffffca73380, 2d83740, 1, 7ffff) >>> perf 5375 [007] 59632.478539: raw_syscalls:sys_exit: NR -1 = 8 >>> perf 5375 [007] 59632.478543: raw_syscalls:sys_enter: NR 16 (4, >>> 2401, 0, 2d83740, 1, 0) >>> perf 5375 [007] 59632.478551: raw_syscalls:sys_exit: NR 16 = 0 >> >> Which architecture? >> For powerpc, see: >> >> static inline int syscall_get_nr(struct task_struct *task, struct pt_regs >> *regs) >> { >> /* >> * Note that we are returning an int here. That means 0xffffffff, ie. >> * 32-bit negative 1, will be interpreted as -1 on a 64-bit kernel. >> * This is important for seccomp so that compat tasks can set r0 = -1 >> * to reject the syscall. >> */ >> return TRAP(regs) == 0xc00 ? regs->gpr[0] : -1; >> } > > So, that's intentional? And has some special meaning? (I confess I don't > understand what the comment is saying exactly.) > > Is this documented? Does something depend on this ABI? > > To me, it just makes parsing more difficult, both by humans and machines.
I should've noted that the instance I encountered was on x86. PC