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

[Mike Frysinger]

On Friday 24 August 2012 08:41:00 Dmitry V. Levin wrote:
> 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:
> > > > * 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)

i don't think there's a real chance (other than the {g,s}etsockopt since 
earlier kernels shipped with the older number).  i wouldn't mind being proven 
wrong though that some people are just really weird/crazy ;).

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

sounds fine to me on both points
-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/20120824/ff6627de/attachment.bin>