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

[Pedro Alves]

On 01/26/2012 08:53 AM, Denys Vlasenko wrote:
> On Thu, Jan 26, 2012 at 9:23 AM, Pedro Alves <palves@xxxxxxxxxx> wrote:
>> On 01/26/2012 12:59 AM, Jamie Lokier wrote:
>>> Tracers mainly want to know if it's a 32-bit or 64-bit syscall, not
>>> whether it's compat as such.
>>
>> Another idea, avoiding new PTRACE_EVENTs per arch, would be to make
>> the abi32/abi64/compat/whatnot discriminator retrievable with PTRACE_GETEVENTMSG
>> instead.  So you'd get PTRACE_EVENT_SYSCALL_ENTRY|EXIT, or the regular old
>> 0x80|SIGTRAP, you'd still fetch the syscall number from $orig_ax (or whatever means
>> for other archs), as usual, then have extra syscall info in PTRACE_GETEVENTMSG.
>> I don't know if it'd be simple to make it possible to do PTRACE_GETEVENTMSG
>> on a 0x80|SIGTRAP trap, but I imagine it so.
>>
>> -> wait
>>  <- 0x80|SIGTRAP   (or PTRACE_EVENT_SYSCALL_ENTRY)
>> -> read regs, find out syscall number
>> -> PTRACE_GETEVENTMSG, figure out which entry mode was used.
> 
> This would require additional ptrace op per syscall entry.
> Linus' method and event method wouldn't.

Yes.

In any case, ptrace events leave recording the state in core files
behind; possibly also important for userspace c/r.
Linus' method or a new regset don't have that drawback.  A new regset requires
an additional ptrace op too, while the former abuses an architecture register,
possibly leading to headaches later on.

-- 
Pedro Alves
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/