Re: kextload failure on 10.5
Re: kextload failure on 10.5
- Subject: Re: kextload failure on 10.5
- From: Terry Lambert <email@hidden>
- Date: Wed, 16 Jun 2010 15:15:25 -0700
On Jun 16, 2010, at 12:22 PM, mogambo wrote:
I am running into another problem while trying to build a universal
kext pkg for a vfs pIugin. I was able to create (lipo separate kext
binaries) a universal binary for the kext that can run on ppc, i386
and x86_64. I also created a universal binary for the mount program
similarly.
The mount program compile cmdlines for i386 and ppc architectures
both have "-isysroot $(SDKROOT10_4) -mmacosx-version-min=10.4", and
the 64-bit version has "-isysroot $(SDKROOT10_6) -mmacosx-version-
min=10.6". However, when I try to run the mount program on Leopard,
it tries to run the 64-bit version and mount() returns EFAULT. I
can understand that a 64-bit mount program cannot work with a 32-bit
kernel extension. The size of mount_data structure, the size of
variables and alignment are all going to be different between the
two. Tracing the kext mount function, I see that it is not even
getting called before the error is returned.
Is there a way to force what arch to run in a universal binary? How
does this work even when the mount program is created with xcode?
There is the "arch" command, but it will probably not be satisfactory
to you. XCode can force the running of the specific architecture of
binary for testing purposes; in order to do this, it it uses an Apple
extension to the posix_spawn(2) implementation, which is documented in
the man pages. However, this will also likely not be satisfatory to
you.
The kernel, if it is capable of running 64 bit binaries, will *always*
preferentially run the 64 bit binaries rather than the 32 bit
binaries. There's no way to say "I want to run 32 bit on Leopard, and
64 bit on SnowLeopard". There's also no way to say "I want to run
whatever bitness the kernel is currently running". The reasons for
this are several, but the primary one is that the machine architecture
and the 32/64 bitness of a binary are unrelated, since machines are
capable of running 32/64 on either 32 or 64 bit kernels. Preference
in user space generally comes down to plug-ins rather than kernel
(e.g. you might have a 32 bit Safari plugin that has not been ported
to 64 bits yet, and so you need to run Safari 32 bit to use the
plugin, etc.).
Several programs do a lot of pig-tricks, which you could do as well;
however, I would not recommend them. The #1 pig trick is to decide
what architecture you "should have been run as" after you are already
running as the "wrong" architecture, and reexec yourself via
posix_spawn(2) with the Apple-extension to pick the slice of the
binary, coupled with the Apple extension to make posix_spawn(2) act
like exec, rather than fork+exec. The flag is also documented in the
manual pages.
The *most correct* way to deal with this is to use sized types in the
data structures you use to communicate between the kernel and user
space, and ensure that the packing doesn't change (either by ordering
larger structure elements first in the structure, or by using #pragma
pack(4) / structure declaration / #pragma pack() or similar element
packing controls).
For example, if you needed to pass a pointer, you would declare the
field as a uint64_t (unsigned long long), cat the pointer to a
uintptr_t, and then assign it into the field. You would never use a
"long" or a pointer type as an element type in a field, and so on.
If the structure size is invariant between the kernel and user space,
it's not going to matter if you are using a 32 bit or 64 bit client to
talk to a 32 bit or 64 bit kernel.
PS: This goes for things like ioctl(2) parameters, as well; if they
are size variant, you will find yourself implementing separate 32 and
64 bit versions of the ioctl(2) command value in the kernel so that
you can deal with both 32 and 64 bit clients; otherwise, the ioctl(2)
case statement number will not match, and it will look like it's an
unrecognized ioctl(2) when you call it from a binary of the "wrong"
bitness.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden