site_archiver@lists.apple.com Delivered-To: darwin-kernel@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@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@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@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@apple.com<mailto:ngervae@apple.com> _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@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@apple.com<mailto:tlambert@apple.com> _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com<mailto:Darwin-kernel@lists.apple.com>) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/sudarshan_swamy%40mcafe... This email sent to sudarshan_swamy@mcafee.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@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@small-tree.com -- Ryan Hankins Software Engineer Small Tree Communications www.small-tree.com rqh@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@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com