site_archiver(a)lists.apple.com
Delivered-To: darwin-kernel(a)lists.apple.com
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
When I used 10.6 sdk, I thought it was a bug in header file as the alias was defined for i386 where as the new symbol was available only on 10.6.
My assumption was that I could always use latest sdk and specify the minimum target using -mmacosx-version-min and that should take care of building a kext that is compatible
for the specified version and onwards. This is the use case if I am recompiling the source that was built with older version of sdk and I am planning to use latest sdk without using any new APIs of new sdk.
This worked for 10.4 and 10.5 sdks, but breaks for 10.6sdk with this alias.
How do I build a universal binary for all 3 platforms (10.4, 10.5 and 10.6) and 3 architectures (ppc, i386 and i64) ?
Should I use 10.4sdk to build i386 and ppc targets and then use 10.6 sdk to build i64 target and then combine it ?
Regards,
Sudarshan
On 28-Apr-2010, at 5:31 AM, Terry Lambert wrote:
You can not specify multiple instances of -isysroot on a per
architecture basis like this. You will need to separately compile your
object files for each architecture and lipo them together.
FWIW, this particular symbol reference results from the
__DARWIN10_ALIAS line in the file Headers/kern/locks.h in the
MacOSX10.6.sdk, so it should be pretty obvious that the final -
isysroot is overriding the previous ones, or you wouldn't be seeing
the symbol.
The reason this exists in the first place here is that there are third
party KEXTs which unlock mutexes which they've already unlocked. In
the 64 bit kernel in 10.6 and later, this intentionally results in a
panic -- it's generally a really bad thing to do, since if you race
someone after the first unlock and before the second, you can zero out
their mutex protection out from under them, and then Bad Things
Happen(tm). Panic'ing existing i386 drivers which already make this
mistake isn't really an option, but neither is letting someone port
bad code over to x86_64 kernels without it barfing. A similar symbol
renaming is in place for IOLockUnlock() for similar reasons.
There are hacky ways to make this alias definition go away, but I'm
not going to document them for you. I use similar things to get
__deprecated implementations to compile so that they can be used by
old code but not if you recompile your old code. 8-). You should
build separate binaries and use lipo, If you want to target older
kernels.
-- Terry
On Apr 27, 2010, at 4:21 PM, mogambo wrote:
Hi Nik,
I see that _lck_mtx_unlock_darwin10 is in Libkern.kext executable on
10.6 only - kextfind reports that it is defined for ppc, i386 and
x86_64. Checking with kextfind and nm/grep does not find
_lck_mtx_unlock_darwin10 on 10.5 and 10.4 (it finds _lck_mtx_unlock
though).
I tried what Shantonu had suggested, but did not quite work. I am
not sure if you saw my reply, but I tried adding arch specific -
isysroot, but got an error:
gcc -arch ppc -Xarch_ppc -isysroot $(SDKROOT) -arch i386 -Xarch_i386
-isysroot $(SDKROOT) -arch x86_64 -Xarch_x86_64 -isysroot $
(SDKROOT10_6)
gcc-4.2: file /Developer/SDKs/MacOSX10.5.sdk specified more than
once on the command line
Note that SDKROOT was 10.5.sdk and SDKROOT10_6 was 10.6.sdk.
-m.
On Mon, Apr 26, 2010 at 5:41 PM, Nik Gervae <ngervae(a)apple.com<mailto:ngervae@apple.com>> wrote:
kextfind was introduced with 10.5, so you won't see it on 10.4. Even
without that, you can use stock development and unix tools....
Try nm on the Libkern.kext executable to see if
_lck_mtx_unlock_darwin10 is there. If it isn't, double-check by
opening the executable in emacs or another raw-text editor and
searching for the string (you can even grep for it). I did note on
my machine that grep found the symbol but nm didn't report it. I
haven't had a chance to dig into why that might be, but it does seem
odd!
The internals of your kext would be the Info.plist and the
executable, if you can send that (do so off-list, of course).
Nik
On 26 Apr, 2010, at 15:45 , mogambo wrote:
Hi Nik,
Here are my findings:
On the 10.6/64-bit where I build the supposed UB:
# nm fsd.kext/Contents/MacOS/fsd | grep darwin10
U _lck_mtx_unlock_darwin10
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.5.7
BuildVersion: 9J61
$ nm fsd.kext/Contents/MacOS/fsd
-bash: nm: command not found
$ kextfind -dsym _lck_mtx_unlock_darwin10
$ <no results>
Yes, com.apple.kernel.libkern is in my OSBundleLibraries. kextfind
does not find the symbols on 10.5, which is what I'd expect since
it's already failing with Undefined Symbol error on 10.5. Somehow
on 10.4 it is able to resolve the symbols. I could not find
kextfind on 10.4, so could not check what defines the symbols there.
I'd be happy to provide all I can to get to the bottom of this
issue. What internals do you need for my kext?
Thanks,
-m.
On Mon, Apr 26, 2010 at 1:47 PM, Nik Gervae <ngervae(a)apple.com<mailto:ngervae@apple.com>>
wrote:
I'm not set up at the moment to diagnose problems *on* 10.5, but I
could check your kext's internals if you want to send it.
Some things you could try are:
nm fsd.kext
kextfind -dsym _lck_mtx_unlock_darwin10
The first dumps all the symbols, so you can double check the nature
of _lck_mtx_unlock_darwin10 (it's probably undefined but maybe
there's a weird problem internally). The kextfind command should
find which kext (if any) defines the symbol that's failing to link:
on my Snow Leopard system it says Libkern.kext
(com.apple.kpi.libkern, not com.apple.kernel.libkern) is the one
that defines it for i386. Is that in your OSBundleLibraries?
I'll have to dig out a 10.5. disk to run kextfind myself, but you
can probably do that directly.
Nik Gervae
Kext Management Engineer
Apple, Inc.
On 23 Apr, 2010, at 15:42 , mogambo wrote:
Hi,
We have a file system driver kext that we build with make. We
build two separate versions for 32- and 64-bit OS X since last year
when 10.6 was released. I did some tweaks to the Makefile and was
able to build a UB on 10.6.2 x86_64 machine containing code for all
3 architectures we support - ppc, i386 and x86_64. I was able to
load the same kext on 10.4/ppc, 10.6/i386 and 10.6/x86_64.
When I tried to load the same kext on a 10.5.7/i386, it failed
with the following errors:
$ sudo kextload fsd.kext
kld(): Undefined symbols:
___stack_chk_fail
___stack_chk_guard
_lck_mtx_unlock_darwin10
kextload: kld_load_from_memory() failed for module /Users/apple/
fsd-47.107/fsd.kext/Contents/MacOS/fsd
kextload: a link/load error occured for kernel extension fsd.kext
link/load failed for extension fsd.kext
(run kextload with -t for diagnostic output)
I added -fno-stack-protector to gcc, which got rid of
stack_chk{fail,guard} errors. However, _lck_mtx_unlock_darwin10
persists.
Here's the gcc command line:
gcc -arch ppc -arch i386 -arch x86_64 -isysroot /Developer/SDKs/
MacOSX10.6.sdk -mmacosx-version-min=10.4 -g -static -nostdinc -Wall
-Wno-switch -fno-stack-protector -msoft-float -mlong-branch -
force_cpusubtype_ALL -fno-builtin -DKERNEL -DAPPLE -D__KERNEL__ -
DKERNEL_PRIVATE -DOPENSSL_NO_STDIO -DOPENSSL_NO_ENGINE -
DOPENSSL_NO_FP_API -DOPENSSL_NO_SHA256 -DOPENSSL_NO_SHA512 -
DOPENSSL_NO_ASM -DNO_OLD_ASN1 -DOPENSSL_NO_DEPRECATED -
DOPENSSL_NO_BIO -DPROFILE -DOPENSSL_NO_ERR -I. -I.. -I/System/
Library/Frameworks/Kernel.framework/Headers -I/System/Library/
Frameworks/Kernel.framework/Headers/bsd -I/Users/apple/workspace/
include -I/Developer/SDKs/MacOSX10.6.sdk -I/usr/include/sys -c
probe.c -o probe.o
The linker command line:
gcc -arch ppc -arch i386 -arch x86_64 -isysroot /Developer/SDKs/
MacOSX10.6.sdk -mmacosx-version-min=10.4 -static -Wall -nostdlib -r
-lkmod -lkmodc++ -lcc_kext -Xlinker -kext -o fsd <list of .o files>
Any ideas?
Thanks!
-m.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com<mailto:Darwin-kernel@lists.apple.com>)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-kernel/ngervae%40apple.com
This email sent to ngervae(a)apple.com<mailto:ngervae@apple.com>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com<mailto:Darwin-kernel@lists.apple.com>)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-kernel/tlambert%40apple.com
This email sent to tlambert(a)apple.com<mailto:tlambert@apple.com>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com<mailto:Darwin-kernel@lists.apple.com>)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-kernel/sudarshan_swamy%40mcaf…
This email sent to sudarshan_swamy(a)mcafee.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-kernel/rqh%40small-tree.com
This email sent to rqh(a)small-tree.com
--
Ryan Hankins Software Engineer
Small Tree Communications www.small-tree.com
rqh(a)small-tree.com +1 651 209-6509 x303
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.…
This email sent to site_archiver(a)lists.apple.com
site_archiver(a)lists.apple.com
Delivered-To: darwin-kernel(a)lists.apple.com
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=CdPgjJ7a3SJLKhkV8ipBpWcGp3Mj84h1GOPZakoX/1c=; b=DZnDxJmOXkWlb5U9FxWY9y99Zjc8xzmE+ayow5qoVurW1P+1sgvayStui7ArcmgC5r XegHYzlvT1BTLSfzPv9v2fLjzCXHjdjT6e7rvQzc2tY7C/BpIYeV5kAS4Nyx3m7u19Vv KIMdpVi2Pd1brkKLGOFg3QRlW8xYjuIAk1wPs=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vY4aK7c/E5dZFsZx+pSUyP5mQiFURf6Z0jMKUfpwc2QWvEMtoQRlPWyLvg1+zDXQAn s+i94BzCBUl5Nwajwk378/pp7okSCgBC3ejpbrVjnLE4KevNq9h+30ExW5ume0NloeBp KTVCfjobgtawxqOovzntGUFYzhyLKdv2x6LkU=
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.…
This email sent to site_archiver(a)lists.apple.com
site_archiver(a)lists.apple.com
Delivered-To: darwin-kernel(a)lists.apple.com
Thread-index: Acrqvq7qX5e553j9TEiTznbw+DZBKQ==
Thread-topic: kextload failure on 10.5
When I used 10.6 sdk, I thought it was a bug in header file as the alias was defined for i386 where as the new symbol was available only on 10.6.
My assumption was that I could always use latest sdk and specify the minimum target using -mmacosx-version-min and that should take care of building a kext that is compatible
for the specified version and onwards. This is the use case if I am recompiling the source that was built with older version of sdk and I am planning to use latest sdk without using any new APIs of new sdk.
This worked for 10.4 and 10.5 sdks, but breaks for 10.6sdk with this alias.
How do I build a universal binary for all 3 platforms (10.4, 10.5 and 10.6) and 3 architectures (ppc, i386 and i64) ?
Should I use 10.4sdk to build i386 and ppc targets and then use 10.6 sdk to build i64 target and then combine it ?
Regards,
Sudarshan
On 28-Apr-2010, at 5:31 AM, Terry Lambert wrote:
You can not specify multiple instances of -isysroot on a per
architecture basis like this. You will need to separately compile your
object files for each architecture and lipo them together.
FWIW, this particular symbol reference results from the
__DARWIN10_ALIAS line in the file Headers/kern/locks.h in the
MacOSX10.6.sdk, so it should be pretty obvious that the final -
isysroot is overriding the previous ones, or you wouldn't be seeing
the symbol.
The reason this exists in the first place here is that there are third
party KEXTs which unlock mutexes which they've already unlocked. In
the 64 bit kernel in 10.6 and later, this intentionally results in a
panic -- it's generally a really bad thing to do, since if you race
someone after the first unlock and before the second, you can zero out
their mutex protection out from under them, and then Bad Things
Happen(tm). Panic'ing existing i386 drivers which already make this
mistake isn't really an option, but neither is letting someone port
bad code over to x86_64 kernels without it barfing. A similar symbol
renaming is in place for IOLockUnlock() for similar reasons.
There are hacky ways to make this alias definition go away, but I'm
not going to document them for you. I use similar things to get
__deprecated implementations to compile so that they can be used by
old code but not if you recompile your old code. 8-). You should
build separate binaries and use lipo, If you want to target older
kernels.
-- Terry
On Apr 27, 2010, at 4:21 PM, mogambo wrote:
Hi Nik,
I see that _lck_mtx_unlock_darwin10 is in Libkern.kext executable on
10.6 only - kextfind reports that it is defined for ppc, i386 and
x86_64. Checking with kextfind and nm/grep does not find
_lck_mtx_unlock_darwin10 on 10.5 and 10.4 (it finds _lck_mtx_unlock
though).
I tried what Shantonu had suggested, but did not quite work. I am
not sure if you saw my reply, but I tried adding arch specific -
isysroot, but got an error:
gcc -arch ppc -Xarch_ppc -isysroot $(SDKROOT) -arch i386 -Xarch_i386
-isysroot $(SDKROOT) -arch x86_64 -Xarch_x86_64 -isysroot $
(SDKROOT10_6)
gcc-4.2: file /Developer/SDKs/MacOSX10.5.sdk specified more than
once on the command line
Note that SDKROOT was 10.5.sdk and SDKROOT10_6 was 10.6.sdk.
-m.
On Mon, Apr 26, 2010 at 5:41 PM, Nik Gervae <ngervae(a)apple.com<mailto:ngervae@apple.com>> wrote:
kextfind was introduced with 10.5, so you won't see it on 10.4. Even
without that, you can use stock development and unix tools....
Try nm on the Libkern.kext executable to see if
_lck_mtx_unlock_darwin10 is there. If it isn't, double-check by
opening the executable in emacs or another raw-text editor and
searching for the string (you can even grep for it). I did note on
my machine that grep found the symbol but nm didn't report it. I
haven't had a chance to dig into why that might be, but it does seem
odd!
The internals of your kext would be the Info.plist and the
executable, if you can send that (do so off-list, of course).
Nik
On 26 Apr, 2010, at 15:45 , mogambo wrote:
Hi Nik,
Here are my findings:
On the 10.6/64-bit where I build the supposed UB:
# nm fsd.kext/Contents/MacOS/fsd | grep darwin10
U _lck_mtx_unlock_darwin10
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.5.7
BuildVersion: 9J61
$ nm fsd.kext/Contents/MacOS/fsd
-bash: nm: command not found
$ kextfind -dsym _lck_mtx_unlock_darwin10
$ <no results>
Yes, com.apple.kernel.libkern is in my OSBundleLibraries. kextfind
does not find the symbols on 10.5, which is what I'd expect since
it's already failing with Undefined Symbol error on 10.5. Somehow
on 10.4 it is able to resolve the symbols. I could not find
kextfind on 10.4, so could not check what defines the symbols there.
I'd be happy to provide all I can to get to the bottom of this
issue. What internals do you need for my kext?
Thanks,
-m.
On Mon, Apr 26, 2010 at 1:47 PM, Nik Gervae <ngervae(a)apple.com<mailto:ngervae@apple.com>>
wrote:
I'm not set up at the moment to diagnose problems *on* 10.5, but I
could check your kext's internals if you want to send it.
Some things you could try are:
nm fsd.kext
kextfind -dsym _lck_mtx_unlock_darwin10
The first dumps all the symbols, so you can double check the nature
of _lck_mtx_unlock_darwin10 (it's probably undefined but maybe
there's a weird problem internally). The kextfind command should
find which kext (if any) defines the symbol that's failing to link:
on my Snow Leopard system it says Libkern.kext
(com.apple.kpi.libkern, not com.apple.kernel.libkern) is the one
that defines it for i386. Is that in your OSBundleLibraries?
I'll have to dig out a 10.5. disk to run kextfind myself, but you
can probably do that directly.
Nik Gervae
Kext Management Engineer
Apple, Inc.
On 23 Apr, 2010, at 15:42 , mogambo wrote:
Hi,
We have a file system driver kext that we build with make. We
build two separate versions for 32- and 64-bit OS X since last year
when 10.6 was released. I did some tweaks to the Makefile and was
able to build a UB on 10.6.2 x86_64 machine containing code for all
3 architectures we support - ppc, i386 and x86_64. I was able to
load the same kext on 10.4/ppc, 10.6/i386 and 10.6/x86_64.
When I tried to load the same kext on a 10.5.7/i386, it failed
with the following errors:
$ sudo kextload fsd.kext
kld(): Undefined symbols:
___stack_chk_fail
___stack_chk_guard
_lck_mtx_unlock_darwin10
kextload: kld_load_from_memory() failed for module /Users/apple/
fsd-47.107/fsd.kext/Contents/MacOS/fsd
kextload: a link/load error occured for kernel extension fsd.kext
link/load failed for extension fsd.kext
(run kextload with -t for diagnostic output)
I added -fno-stack-protector to gcc, which got rid of
stack_chk{fail,guard} errors. However, _lck_mtx_unlock_darwin10
persists.
Here's the gcc command line:
gcc -arch ppc -arch i386 -arch x86_64 -isysroot /Developer/SDKs/
MacOSX10.6.sdk -mmacosx-version-min=10.4 -g -static -nostdinc -Wall
-Wno-switch -fno-stack-protector -msoft-float -mlong-branch -
force_cpusubtype_ALL -fno-builtin -DKERNEL -DAPPLE -D__KERNEL__ -
DKERNEL_PRIVATE -DOPENSSL_NO_STDIO -DOPENSSL_NO_ENGINE -
DOPENSSL_NO_FP_API -DOPENSSL_NO_SHA256 -DOPENSSL_NO_SHA512 -
DOPENSSL_NO_ASM -DNO_OLD_ASN1 -DOPENSSL_NO_DEPRECATED -
DOPENSSL_NO_BIO -DPROFILE -DOPENSSL_NO_ERR -I. -I.. -I/System/
Library/Frameworks/Kernel.framework/Headers -I/System/Library/
Frameworks/Kernel.framework/Headers/bsd -I/Users/apple/workspace/
include -I/Developer/SDKs/MacOSX10.6.sdk -I/usr/include/sys -c
probe.c -o probe.o
The linker command line:
gcc -arch ppc -arch i386 -arch x86_64 -isysroot /Developer/SDKs/
MacOSX10.6.sdk -mmacosx-version-min=10.4 -static -Wall -nostdlib -r
-lkmod -lkmodc++ -lcc_kext -Xlinker -kext -o fsd <list of .o files>
Any ideas?
Thanks!
-m.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com<mailto:Darwin-kernel@lists.apple.com>)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-kernel/ngervae%40apple.com
This email sent to ngervae(a)apple.com<mailto:ngervae@apple.com>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com<mailto:Darwin-kernel@lists.apple.com>)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-kernel/tlambert%40apple.com
This email sent to tlambert(a)apple.com<mailto:tlambert@apple.com>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com<mailto:Darwin-kernel@lists.apple.com>)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-kernel/sudarshan_swamy%40mcaf…
This email sent to sudarshan_swamy(a)mcafee.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.…
This email sent to site_archiver(a)lists.apple.com