[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#708070: enable x32 support for the amd64 kernels



On Fri, 25 Jul 2014, Robert de Bath wrote:

On Fri, 25 Jul 2014, Ben Hutchings wrote:

I had an idea how to unblock this, and finally got round to trying it,
and it seems to work.  That is, we build in x32 support but require a
run-time parameter to enable.  So, please try the attached patch
(against the sid branch), adding "syscall.x32=y" to the kernel command
line.
Okay,
With the flag set the kernel boots happily and runs gcc-mx32 executables.

With the flag off ...
First (simple) thing; with the patch in the kernel tree there is no
configuration to default the x32 switch to on. Thinking ahead to when
this may be well tested, I think it'd be nice if there were a .config
option to default this patch to enabling the x32 syscalls and have a
kernel command line option to disable them in "special cases".

More importantly ...  this is rather ugly; I think you're going to get
complaints when ld.so segfaults.

You may want to reinstate the ENOEXEC error for the 'wrong sort' of executables.

# strace  ./x
execve("./x", ["./x"], [/* 17 vars */]) = 0
[ Process PID=12286 runs in x32 mode. ]
brk(0)                                  = -1 ENOSYS (Function not implemented)
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOSYS (Function not implemented)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOSYS (Function not implemented)
writev(2, [{"./x", 3}, {": ", 2}, {"error while loading shared libra"..., 36}, {": ", 2}, {"", 0}, {"", 0}, {"cannot create cache for search p"..., 35}, {": ", 2}, {"Cannot allocate memory", 22}, {"\n", 1}], 10) = -1 ENOSYS (Function not implemented)
exit_group(127)                         = ?
<... exit_group resumed> _exit returned!
)              = ?
_exit(127)                              = ?
<... _exit resumed> _exit returned!
)                   = ?
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
+++ killed by SIGSEGV +++
Segmentation fault
#


--
Rob.                          (Robert de Bath <robert$ @ debath.co.uk>)
                                             <http://www.debath.co.uk/>


Reply to: