[PATCH] x32: update {g,s}etsockopt syscall numbers

[Mike Frysinger]

On Wednesday 22 August 2012 12:56:36 Dmitry V. Levin wrote:
> On Wed, Aug 22, 2012 at 11:56:15AM -0400, Mike Frysinger wrote:
> > Starting with linux 3.6 (and backported to earlier kernels), these two
> > syscalls have changed numbers (moving from native to compat entry
> > points). Update the strace syscall list accordingly.
> 
> What will happen with applications using old syscall numbers (if any)?
> Will they get ENOSYS?

the 64bit and x32 syscall tables are shared.  so you can call any of the 64bit 
syscalls from an x32 app, and vice versa.  there are a few additional entry 
points which are really there just to map the x86 compat entry points which 
the x32 ABI uses (for when types are different sizes like pointers).

for example, if we look at the rt_sigaction syscall, we see:
	64bit's unisted.h sets the NR to 13
	x32's unistd.h sets the NR to 512

nothing is stopping you from doing syscall(13) in an x32 app, or syscall(512) 
in a 64bit app.  in either case, you won't get ENOSYS because they're both 
valid syscall entry points.  but in most cases, the call won't "work" because 
the types being passed are wrong (which is why we've had to change the NRs 
here in the first place).

> > * linux/x32/syscallent.h: Move setsockopt from 54 to 541, and move
> > getsockopt from 55 to 542.
> > 
> > Signed-off-by: Mike Frysinger <vapier at gentoo.org>
> > ---
> > Note: I'm not sure about the old entry points.  Should they get relabeled
> > 	as "old" ?  Or just leave them as is ?
> 
> From one side, the rule is to stick to __NR_* names as close as possible.
> From another side, it's desirable to decode syscalls on older kernels
> properly.  So maybe we should rather leave old entry points for
> compatibility.

should we fill out the entire table then ?  with the rt_sigaction example above 
(which isn't the only one -- if you look at the x32 syscallent.h, pretty much 
every {} entry is in the same boat), we could label it as "64bit:rt_sigaction" 
or something similarly obvious that the x32 app is most likely doing something 
wrong.  the other problem here is that we can't really decode these syscalls 
properly -- is the app passing up x32 structures (so the syscall will most 
likely fail anyways), or has it manually crafted a 64bit compatible structure 
and passing that up (which would be crazy and generally make no sense) ?

i'm not sure any other arch has taken this approach with a new ABI (using a 
merged system call table), so i'm not sure we have any examples we can consult 
for precedence :(.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20120822/3fcaf191/attachment.bin>