> I took a quick look at the sparc64 tracehook support and only spotted
Thanks for the feedback. The sparc64 (and ia64) code I have is meant
only as a starting point, and there are some unfinished holes. I'd
intended to point you (arch maintainers) at what I whipped up but
leave it to you to decide on the correct arch bits and merge them
eventually. (The x86 and powerpc patches are the only ones I've
really used myself and would submit as claimed to be ready.)
This is true of powerpc too. I guess I'd figured that uses of the
calls would know when it's 32-bit and truncate what they saw. Isn't
that what happens now when a 64-bit ptrace caller uses the 64-bit
getregs flavor on a target task that is actually 32-bit?
But I don't disagree it might well be better for syscall_get_arguments
to truncate values to 32 bits. I don't think there's a need for it to
reflect sign-extended 64-bit values when it's a 32-bit task. Probably
better not to, i.e. see "123 0xffffffff ..." in /proc/pid/syscall on a
64-bit kernel for a 32-bit task as on 32-bit, instead of 32-bit apps
that don't normally notice whether the kernel is 64 or 32 sometimes
seeing "123 0xffffffffffffffff ...".
It's odd that you need sign-extended arguments for all those calls
when other machines don't.
Which call are you talking about? For syscall_get_arguments, I think
it's fine to get all values zero-extended from 32 bits (maybe even
fine to get random high bits). The consumer of those values in the
kernel code ought well enough to know whether it's a 32-bit or 64-bit
task's system call--that changes what the call number and arguments
mean, anyway.
For syscall_set_arguments, it's a different question. In that case,
we should expect that whatever original source of the value being
poked in was, it just knows it's poking a 32-bit task and doesn't even
consider that the kernel might be 64 bits. It should poke a 32-bit
value and have the effect that poking that 32-bit value has on a
32-bit kernel.
Anyway, I don't see how this side of it is really an issue at all.
syscall_set_arguments is only valid to use at the syscall entry
tracing point. This is before the dispatch to those stubs doing the
sign extension. (Or it could be used at a point entirely outside of
syscall entry, like on the state just after -ERESTARTSYS handling
to change the args before the user re-executes the syscall.)
They don't seem to.
Thanks,
Roland
--
