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

[Dmitry V. Levin]

On Wed, Aug 22, 2012 at 02:51:33PM -0400, Mike Frysinger wrote:
> 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).

OK, I've pushed this commit as is.

> > > * 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) ?

If there is a real chance to see these 64bit syscalls used by x32 apps (no
matter how crazy such apps are), would it be better to show syscall names
(e.g. with "64bit:" prefix) rather than their "syscall_*" names, even
without detailed decoding of these syscalls?  What about setting
appropriate sys_flags in these syscall entries so that traditional syscall
filtering would work for them as well?


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20120824/018b5a03/attachment.bin>