January 2010 - Darwin-dev - lists.apple.com

Re: How to get a socket's PID ?
by Jean-Daniel Dupas 12 Jan '10

12 Jan '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Le 12 janv. 2010 à 18:18, Matthew Mashyna a écrit : > I'm working on a project that attempts to monitor some net activity. I'm using libpcap to watch http packets on port 80, for instance. When we see a particular type of http header we want to see what application made the request. pcap will give me the packet, socket, to and from addresses and more. > > I know I can use lsof but that might not be fast enough. I'm looking for a way to do it in C or ObjC. > I don't think this is possible without privilege (and I don't know how to do it either), but as you mention lsof, why did you not download lsof source and look how it does it ? -- Jean-Daniel _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

How to get a socket's PID ?
by Matthew Mashyna 12 Jan '10

12 Jan '10

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com Thanks, Matt _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I'm working on a project that attempts to monitor some net activity. I'm using libpcap to watch http packets on port 80, for instance. When we see a particular type of http header we want to see what application made the request. pcap will give me the packet, socket, to and from addresses and more. I know I can use lsof but that might not be fast enough. I'm looking for a way to do it in C or ObjC. This email sent to site_archiver(a)lists.apple.com

1 0

Re: query on Apple crashreporter logs
by Shantonu Sen 12 Jan '10

12 Jan '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com For the read-only __TEXT segment, there should be no overlaps. Otherwise function calls intended for one of the images at that address would start executing another image's instruction stream, probably resulting in crashes. For dylibs in the shared cache, the writable segments (like __DATA) are not necessarily laid out directly after __TEXT, and can slide independently. So using the __TEXT segments load addresses to infer the __DATA load addresses may result in incorrect assumptions and overlaps, because that's not actually where __DATA is. Shantonu Sent from my MacBook On Jan 12, 2010, at 3:52 AM, Arnab Ganguly wrote: > > Hi All, > I have a very basic query about the binary images loaded in the process as shown by Apple crash report. > > Is there any chance that any of the binaries can have overlapping address space regions? > > > 0x90a71000 - 0x90e2ffea libLAPACK.dylib ??? (???) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib > > 0x90e30000 - 0x90e39fff com.apple.speech.recognition.framework 3.7.24 (3.7.24) <6a6518b392d3d41ace3dcea69d6809d9> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition > > 0x90e3a000 - 0x90e46ffe libGL.dylib ??? (???) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib > > > The above address spaces are unique for each binary so is there a case where we may get some overlapping region or it is absurd. > Thanks in advance. > -A > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-dev/ssen%40apple.com > > This email sent to ssen(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

query on Apple crashreporter logs
by Arnab Ganguly 12 Jan '10

12 Jan '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(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:date:message-id:subject :from:to:content-type; bh=c84WfiIzuWhzQvLsG7fw3VWHZPQM40F0eRf1unAklbM=; b=Cyuhk3jfFJH+2xGQgHV/A5x+YMDVOYpH3+phEjiDQ7kG0w+7zskAUjuZDhJewAwCnW 2HAhrQZAQK058DYnFgrdq1Pw19MDtYVyiio61tCTmyT7lk8KdfM85xtAXk+AemrhSk3c LpOJUu+74/MP4JrhmkL3ZSBNJvFAcUx0kAokI= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=cp8J032tqdJMxsKFz2fvZCio5ON9UO/tXeDoai4N/Gp7qaqhgjf2m4fuYhPcN6kPyo OA5ExltoDV3oglK8v35n/EVyNYy0wvbVYdvHVINqG42TaxITNDueCXYoq0Ita8589wpC YUJnNL2Z66f0FrOY/T41Vcwp7sWDxW2A83wb4= _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: gmp 5.0 link failure on x86_64-apple-darwin10
by Greg Parker 12 Jan '10

12 Jan '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Jan 11, 2010, at 3:51 PM, Jack Howarth wrote: > Does anyone understand the linkage failure of the new gmp 5.0 release > on x86_64-apple-darwin10? The linkage of libgmp.3.dylib fails with the > error... > > ld: in mpn/.libs/gcd_1.o, in section __TEXT,__text reloc 0: not extern and X86_64_RELOC_GOT_LOAD not supported > > Lstrip_x: > mov Ltable@GOTPCREL(%rip), %r9 The linker doesn't like this instruction. At a guess, try this instead: lea Ltable(%rip), %r9 -- Greg Parker gparker(a)apple.com Runtime Wrangler _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

gmp 5.0 link failure on x86_64-apple-darwin10
by Jack Howarth 11 Jan '10

11 Jan '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Mutt/1.5.18 (2008-05-17) Does anyone understand the linkage failure of the new gmp 5.0 release on x86_64-apple-darwin10? The linkage of libgmp.3.dylib fails with the error... ld: in mpn/.libs/gcd_1.o, in section __TEXT,__text reloc 0: not extern and X86_64_RELOC_GOT_LOAD not supported ...where the offending code is generated with... m4 -DOPERATION_gcd_1 `test -f 'gcd_1.asm' || echo './'`gcd_1.asm >tmp-gcd_1.s gcc -std=gnu99 -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo gcd_1 | sed 's/_$//'` -fexceptions -I/sw/include -O2 -pedantic -m64 -mtune=core2 -march=core2 tmp-gcd_1.s -o gcd_1.o rm -f tmp-gcd_1.s The file tmp-gcd_1.s contains... .text .align 6, 0x90 Ltable: .byte 6 .byte 0 .byte 1 .byte 0 .byte 2 .byte 0 .byte 1 .byte 0 .byte 3 .byte 0 .byte 1 .byte 0 .byte 2 .byte 0 .byte 1 .byte 0 .byte 4 .byte 0 .byte 1 .byte 0 .byte 2 .byte 0 .byte 1 .byte 0 .byte 3 .byte 0 .byte 1 .byte 0 .byte 2 .byte 0 .byte 1 .byte 0 .byte 5 .byte 0 .byte 1 .byte 0 .byte 2 .byte 0 .byte 1 .byte 0 .byte 3 .byte 0 .byte 1 .byte 0 .byte 2 .byte 0 .byte 1 .byte 0 .byte 4 .byte 0 .byte 1 .byte 0 .byte 2 .byte 0 .byte 1 .byte 0 .byte 3 .byte 0 .byte 1 .byte 0 .byte 2 .byte 0 .byte 1 .byte 0 .text .align 4, 0x90 .globl ___gmpn_gcd_1 ___gmpn_gcd_1: mov (%rdi), %r8 mov %r8, %r10 or %rdx, %r8 mov $-1, %ecx Ltwos: inc %ecx shr %r8 jnc Ltwos shr %cl, %r10 shr %cl, %rdx mov %ecx, %r8d Ldivide_strip_y: shr %rdx jnc Ldivide_strip_y adc %rdx, %rdx push %r8 push %rdx call ___gmpn_modexact_1_odd pop %rdx pop %r8 test %rax, %rax mov %rax, %rcx jnz Lstrip_x mov %rdx, %rax jmp Ldone Lstrip_x: mov Ltable@GOTPCREL(%rip), %r9 jmp Lstrip_x_top .align 4, 0x90 Ltop: cmovc %r10, %rcx cmovc %rax, %rdx Lstrip_x_top: mov %rcx, %rax and $63, %ecx mov (%r9,%rcx), %cl shr %cl, %rax cmp $6, %cl mov %rax, %rcx mov %rdx, %r10 je Lstrip_x_top sub %rax, %r10 sub %rdx, %rcx jnz Ltop Ldone: mov %r8, %rcx shl %cl, %rax ret whereas the original gcd_1.asm file contains... dnl AMD64 mpn_gcd_1 -- mpn by 1 gcd. dnl Based on the K7 gcd_1.asm, by Kevin Ryde. Rehacked for AMD64 by Torbjorn dnl Granlund. dnl Copyright 2000, 2001, 2002, 2005, 2009 Free Software Foundation, Inc. dnl This file is part of the GNU MP Library. dnl The GNU MP Library is free software; you can redistribute it and/or modify dnl it under the terms of the GNU Lesser General Public License as published dnl by the Free Software Foundation; either version 3 of the License, or (at dnl your option) any later version. dnl The GNU MP Library is distributed in the hope that it will be useful, but dnl WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY dnl or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public dnl License for more details. dnl You should have received a copy of the GNU Lesser General Public License dnl along with the GNU MP Library. If not, see http://www.gnu.org/licenses/. include(`../config.m4') C K8: 6.75 cycles/bit (approx) 1x1 gcd C 10.0 cycles/limb Nx1 reduction (modexact_1_odd) dnl Reduce using x%y if x is more than DIV_THRESHOLD bits bigger than y, dnl where x is the larger of the two. See tune/README for more. dnl dnl div at 80 cycles compared to the gcd at about 7 cycles/bitpair dnl suggests 80/7*2=23 deflit(DIV_THRESHOLD, 23) C table[n] is the number of trailing zeros on n, or MAXSHIFT if n==0. deflit(MAXSHIFT, 6) deflit(MASK, eval((1<<MAXSHIFT)-1)) RODATA ALIGN(64) L(table): .byte MAXSHIFT forloop(i,1,MASK, ` .byte m4_count_trailing_zeros(i) ') C mp_limb_t mpn_gcd_1 (mp_srcptr up, mp_size_t n, mp_limb_t vlimb); C INPUT PARAMETERS define(`up', `%rdi') define(`n', `%rsi') define(`vlimb', `%rdx') TEXT ALIGN(16) PROLOGUE(mpn_gcd_1) mov (%rdi), %r8 C src low limb mov %r8, %r10 or %rdx, %r8 C x | y mov $-1, R32(%rcx) L(twos): inc R32(%rcx) shr %r8 jnc L(twos) shr R8(%rcx), %r10 shr R8(%rcx), %rdx mov R32(%rcx), R32(%r8) C common twos L(divide_strip_y): shr %rdx jnc L(divide_strip_y) adc %rdx, %rdx push %r8 push %rdx CALL( mpn_modexact_1_odd) pop %rdx pop %r8 test %rax, %rax mov %rax, %rcx jnz L(strip_x) mov %rdx, %rax jmp L(done) L(strip_x): LEA( L(table), %r9) jmp L(strip_x_top) ALIGN(16) L(top): cmovc %r10, %rcx C if x-y gave carry, use x,y-x 0 cmovc %rax, %rdx C 0 L(strip_x_top): mov %rcx, %rax C 1 and $MASK, R32(%rcx) C 1 mov (%r9,%rcx), R8(%rcx) C 1 shr R8(%rcx), %rax C 4 cmp $MAXSHIFT, R8(%rcx) C 4 mov %rax, %rcx C 5 mov %rdx, %r10 C 5 je L(strip_x_top) C 5 sub %rax, %r10 C 6 sub %rdx, %rcx C 6 jnz L(top) C 6 L(done): mov %r8, %rcx shl R8(%rcx), %rax ret EPILOGUE() _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kextload bus error on PowerPC
by Ryan McGann 08 Jan '10

08 Jan '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Here is the output from the compiler and linker for the kernel extension (I stopped compiling x86_64 for testing purposes): CompileC /Library/Caches/Build/ProductionBuild.build/Release/KernelExtension.build/Objects-normal/ppc/SquelchCache.o KernelExtension/SquelchCache.c normal ppc c com.apple.compilers.gcc.4_0 cd /Volumes/Development/Source/Perforce_tree_3.0/ setenv LANG en_US.US-ASCII /Developer/usr/bin/gcc-4.0 -x c -arch ppc -fmessage-length=0 -pipe -nostdinc -fno-builtin -Wno-trigraphs -force_cpusubtype_ALL -msoft-float -Os -fno-common -mkernel -finline -fno-keep-inline-functions -DKEXT_DEBUG=0 -DUSE_ENCRYPTED_MD=1 -DVERIFY_TRUST=1 -DDEUCE_IP_ENABLED=1 -DEUCE_STREAM_ENABLED=1 -DKERNEL -DKERNEL_PRIVATE -DDRIVER_PRIVATE -DAPPLE -DNeXT -isysroot /Developer/SDKs/MacOSX10.4.0.sdk -mtune=G5 -mmacosx-version-min=10.4 -gdwarf-2 -I/Library/Caches/Build/ProductionBuild.build/Release/KernelExtension.build/SymIPS.hmap -F/Library/Caches/Build/Release -F/Library/Caches/Build/Release -I/Library/Caches/Build/Release/include -IPongo/FoundationHeaders -IPongo/GlobalHeaders -I/Developer/SDKs/MacOSX10.4.0.sdk/System/Library/Frameworks/Kernel.framework/Headers/machine -I/Library/Caches/Build/Any/include -I/Developer/SDKs/MacOSX10.4.0.sdk/System/Library/Frameworks/Kernel.framework/Headers -I/System/Library/Frameworks/Kernel.framework/Headers/bsd -I/System/Library/Frameworks/Kernel.framework/PrivateHeaders -I/Library/Caches/Build/ProductionBuild.build/Release/KernelExtension.build/DerivedSources/ppc -I/Library/Caches/Build/ProductionBuild.build/Release/KernelExtension.build/DerivedSources -include /var/folders/zz/zzzivhrRnAmviuee+++++++++++/-Caches-/com.apple.Xcode.0/SharedPrecompiledHeaders/Kext_Prefix-ermiczyudsenstebaqblpbrrkpva/Kext_Prefix.h -c /Volumes/Development/Source/Perforce_tree_3.0//KernelExtension/SquelchCache.c -o /Library/Caches/Build/ProductionBuild.build/Release/KernelExtension.build/Objects-normal/ppc/SquelchCache.o Ld /Library/Caches/Build/ProductionBuild.build/Release/KernelExtension.build/Objects-normal/ppc/SymIPS normal ppc cd /Volumes/Development/WorkSource/SymIPS_r3.0 setenv MACOSX_DEPLOYMENT_TARGET 10.4 /Developer/usr/bin/g++-4.0 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4.0.sdk -L/Library/Caches/Build/Release -L/Library/Caches/Build/Release/mNDC/lib -L/Library/Caches/Build/Any/lib -F/Library/Caches/Build/Release -F/Library/Caches/Build/Release -filelist /Library/Caches/Build/ProductionBuild.build/Release/KernelExtension.build/Objects-normal/ppc/KernelExtension.LinkFileList -mmacosx-version-min=10.4 -no_uuid -lndc -lcpp_kext -Xlinker -kext -nostdlib -lkmodc++ /Library/Caches/Build/ProductionBuild.build/Release/KernelExtension.build/Objects-normal/ppc/KernelExtension_info.o -lkmod -lcc_kext -o /Library/Caches/Build/ProductionBuild.build/Release/KernelExtension.build/Objects-normal/ppc/SymIPS CreateUniversalBinary Localization/Universal/PkgRoot/System/Library/Extensions/SymIPS.kext/Contents/MacOS/SymIPS normal "ppc i386" cd /Volumes/Development/WorkSource/SymIPS_r3.0 /usr/bin/lipo -create /Library/Caches/Build/ProductionBuild.build/Release/KernelExtension.build/Objects-normal/ppc/SymIPS /Library/Caches/Build/ProductionBuild.build/Release/KernelExtension.build/Objects-normal/i386/SymIPS -output /Volumes/Development/WorkSource/SymIPS_r3.0/Localization/Universal/PkgRoot/System/Library/Extensions/SymIPS.kext/Contents/MacOS/SymIPS Here is the backtrace from kextload: Process: kextload [148] Path: /sbin/kextload Identifier: kextload Version: ??? (???) Code Type: PPC (Native) Parent Process: SymDaemon [42] Date/Time: 2010-01-06 11:15:34.924 -0800 OS Version: Mac OS X 10.5.8 (9L31a) Report Version: 6 Anonymous UUID: 9E15765F-023C-4D8F-BE1E-089624D2A787 Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000 Crashed Thread: 0 Thread 0 Crashed: 0 com.apple.framework.IOKit 0x941692cc kld_file_prepare_for_link + 200 1 com.apple.framework.IOKit 0x9416b10c __kload_load_modules + 224 2 com.apple.framework.IOKit 0x9416c7b8 kload_load_dgraph + 856 3 com.apple.framework.IOKit 0x941591f4 _KXKextManagerLoadKextUsingOptions + 1272 4 kextload 0x00003800 0x1000 + 10240 5 kextload 0x00001ef4 0x1000 + 3828 Thread 0 crashed with PPC Thread State 32: srr0: 0x941692cc srr1: 0x0200d030 dar: 0x00000000 dsisr: 0x40000000 r0: 0x000006c8 r1: 0xbffff660 r2: 0x00000000 r3: 0x0000b000 r4: 0x00000000 r5: 0x001fc080 r6: 0x000039ea r7: 0x00000000 r8: 0x01ff0000 r9: 0x00000000 r10: 0x00812240 r11: 0x0258a044 r12: 0x93c5ad30 r13: 0x00000000 r14: 0x00000000 r15: 0xfffff704 r16: 0x00000003 r17: 0x00000000 r18: 0x00000000 r19: 0x0000023f r20: 0x000008fc r21: 0x0000023f r22: 0x00000002 r23: 0x024caddb r24: 0x00138df8 r25: 0x00000000 r26: 0x00000008 r27: 0x00138fe0 r28: 0x00000002 r29: 0x001392b0 r30: 0x001392b4 r31: 0x9416920c cr: 0x28422442 xer: 0x20000000 lr: 0x941696a8 ctr: 0x0000000b vrsave: 0x00000000 Binary Images: 0x1000 - 0x5ffe +kextload ??? (???) <5d0882d4d0e957d3e3140664cfc395f7> /sbin/kextload 0x8fe00000 - 0x8fe30c23 dyld 97.1 (???) <89a0055b0e7ea2db881b73c6e63bc774> /usr/lib/dyld 0x90031000 - 0x9003cffb libgcc_s.1.dylib ??? (???) <ea47fd375407f162c76d14d64ba246cd> /usr/lib/libgcc_s.1.dylib 0x90c6d000 - 0x90d92ff3 com.apple.CoreFoundation 6.5.7 (476.19) <dee0f0024f3bf976cfa0a0816e8aa338> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x90e9f000 - 0x90f82fff libobjc.A.dylib ??? (???) <39035ba996e55c617e20595dcd89c063> /usr/lib/libobjc.A.dylib 0x9113d000 - 0x911a4ffb libstdc++.6.dylib ??? (???) <a4e9b10268b3ffac26d0296499b24e8e> /usr/lib/libstdc++.6.dylib 0x92233000 - 0x9225eff7 libauto.dylib ??? (???) <b3a3a4b0f09653bd6d58f1847922b533> /usr/lib/libauto.dylib 0x92788000 - 0x92796fff libz.1.dylib ??? (???) <1a70dd3594a8c5ad39d785af5da23237> /usr/lib/libz.1.dylib 0x93c54000 - 0x93df4ff3 libSystem.B.dylib ??? (???) <900415cd2c829b2de9a6cdcdaa6307e3> /usr/lib/libSystem.B.dylib 0x93f12000 - 0x93f17ff6 libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib 0x94139000 - 0x941ceff7 com.apple.framework.IOKit 1.5.2 (???) <ced0a498252f76a2d2ba9f2a0ae02160> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 0x96f79000 - 0x970c1ff3 libicucore.A.dylib ??? (???) <07d0cefd48d11d5d5b1817c198013f0b> /usr/lib/libicucore.A.dylib 0xfffec000 - 0xfffeffff libobjc.A.dylib ??? (???) /usr/lib/libobjc.A.dylib 0xffff8000 - 0xffff9703 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib And here's the otool -l: Load command 0 cmd LC_SEGMENT cmdsize 600 segname vmaddr 0x00000000 vmsize 0x00076718 fileoff 852 filesize 484956 maxprot 0x00000007 initprot 0x00000003 nsects 8 flags 0x0 Section sectname __text segname __TEXT addr 0x00000000 size 0x00071994 offset 852 align 2^4 (16) reloff 485808 nreloc 29244 flags 0x00000000 reserved1 0 reserved2 0 Section sectname __cstring segname __TEXT addr 0x00071994 size 0x0000138c offset 466152 align 2^2 (4) reloff 0 nreloc 0 flags 0x00000002 reserved1 0 reserved2 0 Section sectname __const segname __TEXT addr 0x00072d20 size 0x00003128 offset 471156 align 2^3 (8) reloff 719760 nreloc 399 flags 0x00000000 reserved1 0 reserved2 0 Section sectname __constructor segname __TEXT addr 0x00075e48 size 0x00000004 offset 483740 align 2^2 (4) reloff 722952 nreloc 1 flags 0x00000000 reserved1 0 reserved2 0 Section sectname __destructor segname __TEXT addr 0x00075e4c size 0x00000004 offset 483744 align 2^2 (4) reloff 722960 nreloc 1 flags 0x00000000 reserved1 0 reserved2 0 Section sectname __data segname __DATA addr 0x00075e50 size 0x0000080c offset 483748 align 2^2 (4) reloff 722968 nreloc 110 flags 0x00000000 reserved1 0 reserved2 0 Section sectname __bss segname __DATA addr 0x0007665c size 0x00000080 offset 0 align 2^2 (4) reloff 0 nreloc 0 flags 0x00000001 reserved1 0 reserved2 0 Section sectname __common segname __DATA addr 0x000766dc size 0x0000003c offset 0 align 2^2 (4) reloff 0 nreloc 0 flags 0x00000001 reserved1 0 reserved2 0 Load command 1 cmd LC_SYMTAB cmdsize 24 symoff 723848 nsyms 503 stroff 729884 strsize 18432 Load command 2 cmd LC_UNIXTHREAD cmdsize 176 flavor PPC_THREAD_STATE count PPC_THREAD_STATE_COUNT r0 0x00000000 r1 0x00000000 r2 0x00000000 r3 0x00000000 r4 0x00000000 r5 0x00000000 r6 0x00000000 r7 0x00000000 r8 0x00000000 r9 0x00000000 r10 0x00000000 r11 0x00000000 r12 0x00000000 r13 0x00000000 r14 0x00000000 r15 0x00000000 r16 0x00000000 r17 0x00000000 r18 0x00000000 r19 0x00000000 r20 0x00000000 r21 0x00000000 r22 0x00000000 r23 0x00000000 r24 0x00000000 r25 0x00000000 r26 0x00000000 r27 0x00000000 r28 0x00000000 r29 0x00000000 r30 0x00000000 r31 0x00000000 cr 0x00000000 xer 0x00000000 lr 0x00000000 ctr 0x00000000 mq 0x00000000 vrsave 0x00000000 srr0 0x00000000 srr1 0x00000000 The panic trace is hard to obtain, since the panic occurs *very* early. The kernel extension is IOKit OSBundleRequired=true so, it's loaded pretty immediately after boot. Firewire debugging is not possible because the Firewire driver doesn't seem to load in time (at least it won't let me attach), and the machine has no IP address. QA took a picture and I can attach it, but having debugged this same issue before, I'm fairly certain it's not very useful. The last time I had this issue, I had to have DTS resolve it, and it turned out to be a problem with the stripping in our kernel extension. The panic log was exactly the same that time, so I double checked the stripping and even turned it off this time. Here's messages from the list that seem to support that theory: http://lists.apple.com/archives/Darwin-drivers/2005/Feb/msg00069.html http://lists.apple.com/archives/darwin-drivers/2002/Sep/msg00013.html Thanks all, Ryan On Thursday, January 07, 2010, at 03:18PM, "Shantonu Sen" <ssen(a)apple.com> wrote: >You still haven't really given enough information, like the kextutil/kextload text output, or the backtrace in gdb (in userspace), or a sample kernel extension/recipe. > >Apple supports kexts that deploy across this range of OSes. We have sample code and WWDC sessions about it. > >I agree with Brian and I think you're wrong about the Mach-O header. The various tools would look at the fat header and gravitate to the ppc/ppc7400 slice. In fact, maybe that's the problem. Are you building with -mmacosx-version-min=10.4? > >Shantonu Sen >ssen(a)apple.com > >Sent from my Mac Pro > >On Jan 7, 2010, at 3:10 PM, Ryan McGann wrote: > >>> * this isn't magic. You have a bus error because of code in your kext >> Well yes, but not really. The bus error is in *kextload*, not my code. In fact, my kext isn't even loaded. That's the problem. >> >>> * ppc machines completely ignore x86_64 architecture. The presence or >>> absence of such code in your kext is not relevant. >> Well, again not really. Once the kext is loaded that's true, but kextload (and libsa) both look at the Mach header of the kernel extension, and do some sanity checking. Because IOKit in 10.5 does not recognize the 64-bit architecture in the Mach header, it chokes on 64-bit kernel extensions when using -t with a bogus error message ("Executable does not contain kernel code"). This is a documented problem that you can find online from a lot of people, but it's a bogus error message, and therefore it's neither here nor there. >> >>> * you should use two machine debugging to diagnose this. You can use >>> an intel machine to connect to your ppc panic; just specify the -arch >>> keyword when invoking gdb >> Sorry, I'm kind of assuming previous experience that I've had with this. The panic is basically a red herring as well. The panic is the same as the kextload issue; the in-kernel linker is experiencing the same bus error that kextload experiences in userspace. Two machine debugging won't tell me anything because (a) our kernel extension is not in the backtrace, it's all in the kernel linker and (b) I know what the problem is—the kernel extension is somehow malformed—because kextload can't load the kext either. >> >> I'm just curious if anybody else has seen the same crash in kextload with a similar setup, and if they found a workaround. >> >> Ryan >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/darwin-dev/ssen%40apple.com >> >> This email sent to ssen(a)apple.com > > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kextload bus error on PowerPC
by Iceberg-Dev 07 Jan '10

07 Jan '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:mime-version:in-reply-to :references:content-type:message-id:content-transfer-encoding:from :subject:date:to:x-mailer; bh=1encM4dDOCA4M22D7E3OOIiH1/+l4Bscdknb8qzEPwk=; b=Kg5NHcNB9ezYfpzioZU0+5dAL1MEcOaytg0lItsGwU/RZyLbXY3Z0HeaLx6NdyUlmb LR86N2Xk/BN+m8AgnuvPJwYtAr9jKld5CnMpQ84OidHD+9Rtx5gZAfYW84wsGQ3kMYsn 3hh2Gl8R2zwduYUgUQ3183mq73E7p/21G4hY0= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:content-type:message-id :content-transfer-encoding:from:subject:date:to:x-mailer; b=gESsc4eDTHoCiMnWf+LFkagcqJpif5T6SBWqgK1D06vwcXVPcUvvNDOxy4i9W9XxYL mGx2emE6Cosc6PjY0w9gRmelZ9GgEXoEK0QK3+wzg+03ZO4j+wnp9CiobhWxEX98HWoM RqloCpIUF2pOl+SpMv0NJz97s+NKWSoMHph6w= On Jan 7, 2010, at 1:58 AM, Ryan McGann wrote: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I am working with an IOKit kernel extension (OSBundleRequired == "Root") that is built on Snow Leopard/Intel, but is targeting 10.4, 10.5 and 10.6 on PowerPC, i386 and x86_64. The i386 version of the kext loads and works fine, but I am having a problem with my PowerPC kernel extension (Tiger or Leopard). The machine panics pretty quickly after startup. When I boot in safe mode and load the kext manually, kextload complains "Executable does not contain kernel extension code". I figured out this was due to the presence of the x86_64 slice in the binary, so I tried building without that slice. kextload then says that the kernel extension can be loaded, but I just get a bus error. I tried all the usual suspects—turning off all stripping, removing the LC_UUID load command using strip, and more. No avail—the i386 version works fine on all platforms, so I can't figure out what the difference is between ppc and i386. If the bus error is in user land with the kextload tool, maybe you can build the kextload tool from the Darwin source code, run it in debug mode step by step and see where exactly the error occurs. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kextload bus error on PowerPC
by Shantonu Sen 07 Jan '10

07 Jan '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com You still haven't really given enough information, like the kextutil/kextload text output, or the backtrace in gdb (in userspace), or a sample kernel extension/recipe. Apple supports kexts that deploy across this range of OSes. We have sample code and WWDC sessions about it. I agree with Brian and I think you're wrong about the Mach-O header. The various tools would look at the fat header and gravitate to the ppc/ppc7400 slice. In fact, maybe that's the problem. Are you building with -mmacosx-version-min=10.4? Shantonu Sen ssen(a)apple.com Sent from my Mac Pro On Jan 7, 2010, at 3:10 PM, Ryan McGann wrote: >> * this isn't magic. You have a bus error because of code in your kext > Well yes, but not really. The bus error is in *kextload*, not my code. In fact, my kext isn't even loaded. That's the problem. > >> * ppc machines completely ignore x86_64 architecture. The presence or >> absence of such code in your kext is not relevant. > Well, again not really. Once the kext is loaded that's true, but kextload (and libsa) both look at the Mach header of the kernel extension, and do some sanity checking. Because IOKit in 10.5 does not recognize the 64-bit architecture in the Mach header, it chokes on 64-bit kernel extensions when using -t with a bogus error message ("Executable does not contain kernel code"). This is a documented problem that you can find online from a lot of people, but it's a bogus error message, and therefore it's neither here nor there. > >> * you should use two machine debugging to diagnose this. You can use >> an intel machine to connect to your ppc panic; just specify the -arch >> keyword when invoking gdb > Sorry, I'm kind of assuming previous experience that I've had with this. The panic is basically a red herring as well. The panic is the same as the kextload issue; the in-kernel linker is experiencing the same bus error that kextload experiences in userspace. Two machine debugging won't tell me anything because (a) our kernel extension is not in the backtrace, it's all in the kernel linker and (b) I know what the problem is—the kernel extension is somehow malformed—because kextload can't load the kext either. > > I'm just curious if anybody else has seen the same crash in kextload with a similar setup, and if they found a workaround. > > Ryan > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-dev/ssen%40apple.com > > This email sent to ssen(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kextload bus error on PowerPC
by Ryan McGann 07 Jan '10

07 Jan '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com >* this isn't magic. You have a bus error because of code in your kext Well yes, but not really. The bus error is in *kextload*, not my code. In fact, my kext isn't even loaded. That's the problem. >* ppc machines completely ignore x86_64 architecture. The presence or >absence of such code in your kext is not relevant. Well, again not really. Once the kext is loaded that's true, but kextload (and libsa) both look at the Mach header of the kernel extension, and do some sanity checking. Because IOKit in 10.5 does not recognize the 64-bit architecture in the Mach header, it chokes on 64-bit kernel extensions when using -t with a bogus error message ("Executable does not contain kernel code"). This is a documented problem that you can find online from a lot of people, but it's a bogus error message, and therefore it's neither here nor there. >* you should use two machine debugging to diagnose this. You can use >an intel machine to connect to your ppc panic; just specify the -arch >keyword when invoking gdb Sorry, I'm kind of assuming previous experience that I've had with this. The panic is basically a red herring as well. The panic is the same as the kextload issue; the in-kernel linker is experiencing the same bus error that kextload experiences in userspace. Two machine debugging won't tell me anything because (a) our kernel extension is not in the backtrace, it's all in the kernel linker and (b) I know what the problem is—the kernel extension is somehow malformed—because kextload can't load the kext either. I'm just curious if anybody else has seen the same crash in kextload with a similar setup, and if they found a workaround. Ryan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0