32-bit binaries (e.g. wine) and 64-bit kernel structures

[John Baldwin]

On Sunday, October 23, 2011 7:04:51 pm Li-Lun "Leland" Wang wrote:
> Hi,
> 
> Although I only encounter this kind of problem when running wine
> (because it is one of the few ports that need to compile into 32-bit),
> it is a problem of i386 binaries on x64 FreeBSD in general.
> 
> The problem that I'm running into recently is
> http://bugs.winehq.org/show_bug.cgi?id=28857 .
> In short, wine recently implemented GetUdpTable() for Mac OS and BSD.
> It uses sysctlbyname() to get net.inet.udp.pcblist, and parses it into
> xinpgen structures.  However, the size of xinpgen is different on i386
> and x64.  As a result, when I run applications that call
> GetUdpTable(), the kernel supplies wine with 64-bit structures, while
> wine expects 32-bit structures, and crashes.  They decided that this
> is a FreeBSD bug rather than a wine bug, and that the kernel or LD
> should know a 32-bit binary is being run and return proper structures,
> as is done in Mac OS.
> 
> xinpgen is not the only structure of wrong sizes for 32-bit binaries
> on x64.  A while ago I was trying to make my usb gamepad work on wine
> using the ugen device.  libusbhid uses ioctl to get the
> usb_gen_descriptor structure, which is also of different sizes on i386
> and x64.  I had to manually "pad" the pointers to 64-bit and build a
> custom libusbhid for it to work.
> 
> As it stands, they will probably not fix GetUdpTable() on wine side,
> and any windows applications that uses GetUdpTable() will not run
> properly in wine on FreeBSD x64.  Do we have plans to fix this kind of
> problems in general?  Although wine port on FreeBSD is only supported
> for ARCH=i386, could there be workarounds?

Fixing this problem generically is very hard.  Instead, we have patched
individual sysctls and ioctls on a case-by-case basis.

I do think newer interfaces often opt to use fixed-size types so that
the structure is the same for both 32-bit and 64-bit, but that will not
work for existing interfaces.

-- 
John Baldwin