Undefined symbols for architecture armv7?

[rzhikharevich]

I didn't encounter these errors on earlier versions: ... Undefined symbols for architecture armv7: "divsi3189", referenced from: IOService::notifyControllingDriverDone() in IOServicePM.cpo "udivsi3190", referenced from: IOService::tellClientsWithResponse(int) in IOServicePM.cpo "udivsi3281", referenced from: IOPMrootDomain::sysPowerDownHandler(void, void, unsigned long, IOService, void, unsigned int) in IOPMrootDomain.cpo "udivsi3282", referenced from: IOPMrootDomain::handleAggressivesRequests() in IOPMrootDomain.cpo "udivsi3283", referenced from: IOPMrootDomain::handleAggressivesRequests() in IOPMrootDomain.cpo "udivsi3284", referenced from: IOPMrootDomain::getAggressiveness(unsigned long, unsigned long_) in IOPMrootDomain.cpo "udivsi362", referenced from: IOGeneralMemoryDescriptor::dmaCommandOperation(unsigned long, void, unsigned int) const in IOMemoryDescriptor.cpo "__udivsi363", referenced from: IOGeneralMemoryDescriptor::wireVirtual(IODirection) in IOMemoryDescriptor.cpo "udivsi364", referenced from: IOGeneralMemoryDescriptor::complete(IODirection) in IOMemoryDescriptor.cpo "_udivsi392", referenced from: _hibernate_write_image in IOHibernateIO.cpo "___udivsi394", referenced from: ProgressUpdate(hibernate_graphicst, unsigned char, int, int) in IOHibernateIO.cpo "udivsi395", referenced from: _hibernate_machine_init in IOHibernateIO.cpo "_umodsi310", referenced from: OSSymbolPool::removeSymbol(OSSymbol) in OSSymbol.cpo "umodsi39", referenced from: OSSymbolPool::findSymbol(char const_) const in OSSymbol.cpo "_memcpy2", referenced from: IODataQueue::setNotificationPort(ipcport) in IODataQueue.cpo "_memcpy417", referenced from: OSKext::getKmodInfo(kmod_info_, unsigned int) in OSKext.cpo "_memcpy91", referenced from: _IOHibernateSystemSleep in IOHibernateIO.cpo "memset13", referenced from: IOMemoryCursor::genPhysicalSegments(IOMemoryDescriptor, unsigned long, void, unsigned long, unsigned long, unsigned long) in IOMemoryCursor.cpo "memset188", referenced from: IOService::addPowerChild(IOService) in IOServicePM.cpo "_memset93", referenced from: ProgressUpdate(hibernate_graphicst, unsigned char_, int, int) in IOHibernateIO.cpo ld: symbol(s) not found for architecture armv7 ... I am trying to compile it for S5L8930 (Apple A4). I have Xcode 6.0.1 installed.

[rzhikharevich]

Maybe the problem is in iOS 8.0 SDK?

[return]

I have the same issue whilst compiling the kernel on Xcode 6, and I managed to compile it on Xcode 5.1.1 with iOS 6.1 SDK.

[b-man]

Hello guys

My theory behind this problem is that more recent versions of Xcode don't provide a toolchain that gives you an armv7 build of the libclang_rt.cc_kext.a library (I can't say with certainty as I don't have access to a Mac atm).

To work around this problem for good, I've integrated a subset of the APIs provided by libclang_rt.cc_kext into the source tree under osfmk/arm/crt. If you have any more linker errors (or any other related questions), feel free to post them here and I'll do my best to resolve those errors/answer questions.

[nightsuns]

i just use the latest version of master branch in repo, still has error:

make TARGET_CONFIGS="debug arm OMAP3530"

CC version.o LD mach_kernel.sys Undefined symbols for architecture armv7: "divsi3189", referenced from: IOService::notifyControllingDriverDone() in IOServicePM.cpo "udivsi3190", referenced from: IOService::tellClientsWithResponse(int) in IOServicePM.cpo "udivsi3281", referenced from: IOPMrootDomain::sysPowerDownHandler(void, void, unsigned long, IOService, void, unsigned int) in IOPMrootDomain.cpo "udivsi3282", referenced from: IOPMrootDomain::handleAggressivesRequests() in IOPMrootDomain.cpo "udivsi3283", referenced from: IOPMrootDomain::handleAggressivesRequests() in IOPMrootDomain.cpo "udivsi3284", referenced from: IOPMrootDomain::getAggressiveness(unsigned long, unsigned long_) in IOPMrootDomain.cpo "udivsi362", referenced from: IOGeneralMemoryDescriptor::dmaCommandOperation(unsigned long, void, unsigned int) const in IOMemoryDescriptor.cpo "__udivsi363", referenced from: IOGeneralMemoryDescriptor::wireVirtual(IODirection) in IOMemoryDescriptor.cpo "udivsi364", referenced from: IOGeneralMemoryDescriptor::complete(IODirection) in IOMemoryDescriptor.cpo "_udivsi392", referenced from: _hibernate_write_image in IOHibernateIO.cpo "___udivsi394", referenced from: ProgressUpdate(hibernate_graphicst, unsigned char, int, int) in IOHibernateIO.cpo "udivsi395", referenced from: _hibernate_machine_init in IOHibernateIO.cpo "_umodsi310", referenced from: OSSymbolPool::removeSymbol(OSSymbol) in OSSymbol.cpo "umodsi39", referenced from: OSSymbolPool::findSymbol(char const_) const in OSSymbol.cpo "_memcpy2", referenced from: IODataQueue::setNotificationPort(ipcport) in IODataQueue.cpo "_memcpy417", referenced from: OSKext::getKmodInfo(kmod_info_, unsigned int) in OSKext.cpo "_memcpy91", referenced from: _IOHibernateSystemSleep in IOHibernateIO.cpo "memset13", referenced from: IOMemoryCursor::genPhysicalSegments(IOMemoryDescriptor, unsigned long, void, unsigned long, unsigned long, unsigned long) in IOMemoryCursor.cpo "memset188", referenced from: IOService::addPowerChild(IOService) in IOServicePM.cpo "_memset93", referenced from: ProgressUpdate(hibernate_graphicst, unsigned char_, int, int) in IOHibernateIO.cpo ld: symbol(s) not found for architecture armv7 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: * [/Volumes/Work/opensourcelib/arm_xnu/xnu/BUILD/obj//DEBUG_ARM_OMAP3530/./mach_kernel] Error 1 make[1]: * [build_all] Error 2 make: *\ [all] Error 2

for example: _divsi3189 , is not exist, it's just divsi3.

[b-man]

Hello nightsuns,

Could you post the clang version and development environment you are using?

[rzhikharevich]

b-man, I still have that error. Xcode version: 6.1 Clang version: 600.0.54

[return]

The same errors still exist on Xcode 6.1 (6A1052d) when I compiled the xnu on my system. My clang version is 600.0.54.

[b-man]

Hmm, for some reason Xcode 6.1's clang++ is mangling those functions (I'm running a slightly older version of clang which isn't showing this problem). I'll see what I can do tonight and hopefully I'll have a solution tomorrow.

[nightsuns]

@b-man, below is my version:

Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.0.0 Thread model: posix

xcode: Version 6.1 (6A1052d)

host: OSX 10.10.1 (14B25)

[b-man]

Hmm, I'm using a build of clang-503.0.38 (Xcode 5.1) from Apple's open source release to build xnu without issues. What is strange about this problem is that after looking back at my builds, my version of clang seems to do the same thing to these functions (with slightly different results) yet it is able to successfully link the kernel. Perhaps something has changed with the linker (or clang) and these differences are causing this problem? Nonetheless I'll hopefully have a (hackish) solution to this problem tomorrow.

Worst case scenario I'll need to replace these assembly functions with C equivalents which would probably have an impact on performance. :(

[nightsuns]

@b-main: thanks for your reply, if you have patch, i could help to do the test.

[b-man]

nightsuns,

Here's a patch containing my (hacky) solution

diff -Naur xnu-old/osfmk/arm/bcopy.s xnu-new/osfmk/arm/bcopy.s
--- xnu-old/osfmk/arm/bcopy.s   2014-12-01 13:54:52.442265996 -0500
+++ xnu-new/osfmk/arm/bcopy.s   2014-12-01 14:10:26.802315810 -0500
@@ -29,7 +29,9 @@

 .text
 .align 2
-       
+       .globl _memcpy91
+       .globl _memcpy417
+       .globl _memcpy2
        .globl _memcpy
        .globl _bcopy
        .globl _memmove
diff -Naur xnu-old/osfmk/arm/bzero.s xnu-new/osfmk/arm/bzero.s
--- xnu-old/osfmk/arm/bzero.s   2014-12-01 13:54:52.442265996 -0500
+++ xnu-new/osfmk/arm/bzero.s   2014-12-01 14:12:54.890323705 -0500
@@ -33,6 +33,9 @@
        .text
        .align 2

+       .globl _memset188
+       .globl _memset93
+       .globl _memset13
        .globl _memset
 /* void *memset(void *ptr, int c, size_t len); */
 _memset:
diff -Naur xnu-old/osfmk/arm/crt/divsi3.s xnu-new/osfmk/arm/crt/divsi3.s
--- xnu-old/osfmk/arm/crt/divsi3.s      2014-12-01 13:54:52.442265996 -0500
+++ xnu-new/osfmk/arm/crt/divsi3.s      2014-12-01 13:56:35.478271489 -0500
@@ -15,6 +15,7 @@
 .extern ___udivsi3

 EnterARM(__divsi3)
+EnterARM_NoAlign(__divsi3189)
   eor  r3, r0, r0, asr #31
   eor  r2, r1, r1, asr #31
   stmfd  sp!, {r4, r5, r7, lr}
diff -Naur xnu-old/osfmk/arm/crt/udivsi3.s xnu-new/osfmk/arm/crt/udivsi3.s
--- xnu-old/osfmk/arm/crt/udivsi3.s     2014-12-01 13:54:52.442265996 -0500
+++ xnu-new/osfmk/arm/crt/udivsi3.s     2014-12-01 14:05:11.694299010 -0500
@@ -13,6 +13,17 @@
 #include <arm/asm_help.h>

 EnterARM(__udivsi3)
+EnterARM_NoAlign(__udivsi362)
+EnterARM_NoAlign(__udivsi363)
+EnterARM_NoAlign(__udivsi364)
+EnterARM_NoAlign(__udivsi392)
+EnterARM_NoAlign(__udivsi394)
+EnterARM_NoAlign(__udivsi395)
+EnterARM_NoAlign(__udivsi3190)
+EnterARM_NoAlign(__udivsi3281)
+EnterARM_NoAlign(__udivsi3282)
+EnterARM_NoAlign(__udivsi3283)
+EnterARM_NoAlign(__udivsi3284)
   cmp  r1, #0
   cmpne  r0, #0
   stmfd  sp!, {r4, r5, r7, lr}
diff -Naur xnu-old/osfmk/arm/crt/umodsi3.s xnu-new/osfmk/arm/crt/umodsi3.s
--- xnu-old/osfmk/arm/crt/umodsi3.s     2014-12-01 13:54:52.442265996 -0500
+++ xnu-new/osfmk/arm/crt/umodsi3.s     2014-12-01 14:07:34.386306618 -0500
@@ -15,6 +15,8 @@
 .extern ___udivsi3

 EnterARM(__umodsi3)
+EnterARM_NoAlign(__umodsi39)
+EnterARM_NoAlign(__umodsi310)
   stmfd  sp!, {r4, r5, r7, lr}
   add  r7, sp, #8
   mov  r5, r0

[nightsuns]

@b-man : after apply this patch, still has some error:

CC version.o LD mach_kernel.sys Undefined symbols for architecture armv7: "_memcpy2", referenced from: IODataQueue::setNotificationPort(ipcport) in IODataQueue.cpo "_memcpy417", referenced from: OSKext::getKmodInfo(kmod_info_, unsigned int) in OSKext.cpo "_memcpy91", referenced from: _IOHibernateSystemSleep in IOHibernateIO.cpo "memset13", referenced from: IOMemoryCursor::genPhysicalSegments(IOMemoryDescriptor, unsigned long, void, unsigned long, unsigned long, unsigned long) in IOMemoryCursor.cpo "memset188", referenced from: IOService::addPowerChild(IOService) in IOServicePM.cpo "_memset93", referenced from: ProgressUpdate(hibernate_graphicst, unsigned char_, int, int) in IOHibernateIO.cpo ld: symbol(s) not found for architecture armv7 clang: error: linker command failed with exit code 1 (use -v to see invocation)

[b-man]

Sorry about taking a while to reply It looks like those errors are the result of how those symbols are exported (they don't use EnterARM/EnterThumb). I'll see what I can do to fix this. I'm also installing a copy of OSX 10.10 in VMWare so I can investigate why Xcode 6.1's clang is having problems linking the kernel properly and hopefully come up with a proper solution to this problem.

[b-man]

zhikharevich, nightsuns

I've implemented a fix that should resolve those linker errors. Please let me know if it works.

[nightsuns]

@b-man : thanks for the fix, it's ok for me.

[return]

I can confirm that this also compiles on Xcode 6.1.1 which was updated recently. Thanks b-man.

[minux]

do we understand why the symbols are mangled in the first place yet? I think the fix is just a workaround.

[b-man]

minux,

It is indeed a workaround. For some yet to be known reason Xcode 6.x's toolchain (allegedly clang++ or the linker) is not recognizing that idivsi3/udivsi3/umodsi3/ect are intrinsic functions (what would normally be found in compiler_rt) and is thus treating these symbols like regular c/assembly function names.

If anyone has a better solution for this problem (apart from creating a custom toolchain for OSX) I'm open to suggestions. I've spent the last two days trying to figure out why this is happening with this particular toolchain, and so far aliasing the symbols seems to be the cleanest solution for now. I know it's an ugly hack, but it works for now. ;)

[nightsuns]

@b-man : after update the source, i run on a qemu-arm,it's crash, the output is below:

qemu-system-arm -s -S -machine realview-pb-a8 -m 1024 -kernel GenericBooter/SampleBooter.elf.uImage -append rd=md0 debug=0x16e serial=3 -v -s -serial stdio

debug_init()

:: :: GenericBooter for ARM RealView, Copyright 2013, winocm. :: :: BUILD_TAG: :: :: BUILD_STYLE: DEVELOPMENT :: :: COMPILE_DATE: Dec 5 2014 17:21:49

::

preparing system... image3_get_tag_data: data at 0x80008080 of size 0x009fb120 for image type 'krnl' Loading kernel at 0x70001000 image3_get_tag_data: data at 0x81a03210 of size 0x00000a5b for image type 'xmdt' image3_get_tag_data: data at 0x80a031e0 of size 0x01000000 for image type 'rdsk' creating ramdisk at 0x70a44000 of size 0x1000000, from image at 0x80a031e0 creating device tree at 0x71a44000 of size 0x9f8 gBootArgs.commandLine = [rd=md0 debug=0x16e serial=3 -v -s] kernel prepped at 0x7012e8e0, transferring control out of booter now! PE_RealView: pic at 0xc0002000, distribution at 0xc0003000 cache: initializing i+dcache ... done Serial mode specified: 00000003 CPU: Cortex A8-r0 rev 0 (Cortex-A core) Supported features: ARM_ISA THUMB2 THUMBEE ARMv4 Security_Ext WB enabled LABT branch prediction enabled LoUU:2 LoC:2 LoUIS:1 Cache level 1: 16KB/64B 4-way data cache WT WB Read-Alloc 16KB/64B 4-way instruction cache Read-Alloc Darwin Kernel Version 13.0.0: Fri Dec 5 11:47:48 CST 2014; nightsuns:xnu/BUILD/obj//DEBUG_ARM_ARMPBA8 pmap_steal_memory: C0307000 - C0309000; size=00002000 pmap_steal_memory: C0309000 - C030A000; size=00001000 pmap_steal_memory: C030A000 - C0310000; size=00006000 pmap_steal_memory: C0310000 - C0390000; size=00080000 pmap_steal_memory: C0390000 - C03E0000; size=00050000 pmap_steal_memory: C03E0000 - C08F8E58; size=00518E58 Filling vm_pages with pattern: 0xdeb8f177 vm_page_bootstrap: 121474 free pages and 9598 wired pages [ASID configuration start] PMAP: enabled ASID support All ASID/asids enabled: real_ncpus: 1, pmap_asid_ncpus: 1 kext submap [0x80000000 - 0xfffeffff], kernel text [0x80001000 - 0x806c8000] zone leak detection disabled Scheduler: Default of traditional standard timeslicing quantum is 10000 us standard background quantum is 2500 us mig_table_max_displ = 74 PE_RealView: decrementer frequency = 5000 PE_RealView: RealView Timer initialized, Timer value 4773 rtclock_bus_configure: Configuring RTCLOCK... [RTCLOCK] Frequency = 1.000000MHz, cvtt2n = 000003E8.00000000, cvtn2t = 00000000.00418937 Initializing serial KDP Kernel boot args: 'rd=md0 debug=0x16e serial=3 -v -s' iBoot version: iBoot-1234.56.7 PE_init_iokit: starting IOKit now! COLOR video console at 0xc0007000 (1024x768x32) COLOR video console at 0xc0007000 (1024x768x32) Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved.

MAC Framework successfully initialized using 2621 buffer headers and 2621 cluster IO buffer headers AppleARMPE::start: Welcome to the NeXT generation. AppleARMCPU::start: Starting ARM CPU IOKit provider... AppleARMCPU::initCPU(0xc0e92760): we are here to serve! AppleARMCPU::start: registered processor with Mach subsystem. AppleARMIO::start: Publishing device tree entries to IOService plane... MAC Framework enabling singlelabel support: -> () mcache_create: bkt_1 (i) arg 0 bufsize 8 align 8 chunksize 24 bktsize 47 mcache_create: bkt_3 (i) arg 0 bufsize 16 align 8 chunksize 32 bktsize 47 mcache_create: bkt_7 (i) arg 0 bufsize 32 align 8 chunksize 48 bktsize 47 mcache_create: bkt_15 (i) arg 0 bufsize 64 align 8 chunksize 80 bktsize 31 mcache_create: bkt_31 (i) arg 0 bufsize 128 align 8 chunksize 144 bktsize 31 mcache_create: bkt_47 (i) arg 0 bufsize 192 align 8 chunksize 208 bktsize 31 mcache_create: bkt_63 (i) arg 0 bufsize 256 align 8 chunksize 272 bktsize 15 mcache_create: bkt_95 (i) arg 0 bufsize 384 align 8 chunksize 400 bktsize 15 mcache_create: bkt_143 (i) arg 0 bufsize 576 align 8 chunksize 592 bktsize 15 mcache_create: bkt_165 (i) arg 0 bufsize 664 align 8 chunksize 680 bktsize 15 mcache_create: audit (i) arg 0 bufsize 168 align 8 chunksize 184 bktsize 31 mcache_create: mcl_audit_contents (i) arg 0 bufsize 120 align 8 chunksize 136 bktsize 31 mcache_create: mext_ref (i) arg 0 bufsize 8 align 8 chunksize 24 bktsize 47 mcache_create: mbuf (e) arg 0 bufsize 256 align 1 chunksize 256 bktsize 31 mcache_create: cl (e) arg 0x1 bufsize 2048 align 1 chunksize 2048 bktsize 7 mcache_create: bigcl (e) arg 0x2 bufsize 4096 align 1 chunksize 4096 bktsize 3 mcache_create: 16kcl (e) arg 0x3 bufsize 16384 align 1 chunksize 16384 bktsize 1 mcache_create: mbuf_cl (e) arg 0x4 bufsize 2048 align 1 chunksize 2048 bktsize 7 mcache_create: mbuf_bigcl (e) arg 0x5 bufsize 4096 align 1 chunksize 4096 bktsize 3 mcache_create: mbuf_16kcl (e) arg 0x6 bufsize 16384 align 1 chunksize 16384 bktsize 1 mbinit: done [32 MB total pool size, (21/10) split] Pthread support ABORTS when sync kernel primitives misused bsd_autoconf: calling kminit lo0: attached lo0: attached v2 protocol 30 panic(cpu 0 caller 0x80128cdb): Kernel data abort. (faulting address: 0x00000003, saved state 0xca76b8d8) r0: 0x00000003 r1: 0xca76bae4 r2: 0xc1027718 r3: 0x59414e41 r4: 0x59414e41 r5: 0xffffffff r6: 0xffffffff r7: 0xca76b94c r8: 0x000ff000 r9: 0x00000034 r10: 0x00000000 r11: 0x00000000 12: 0xc1027738 sp: 0xca76b928 lr: 0x801e0a35 pc: 0x804f4f1a cpsr: 0x200001f3 fsr: 0x00000005 far: 0x00000003

Debugger called: Debugger called: Backtrace (CPU 0), Frame : Return Address 0xca76b690 : 0x8011f107 mach_kernel : _DebuggerWithContext + 0x23 0xca76b6a8 : 0x80032ecd mach_kernel : _panic_context + 0xf1 0xca76b6e0 : 0x80128cdb mach_kernel : _sleh_abort + 0x4e7 0xca76b8c0 : 0x200001f3 can't perform kext scan: no kext summary BSD process name corresponding to current thread: Unknown Boot args: rd=md0 debug=0x16e serial=3 -v -s

Mac OS version: Not yet set

Kernel version: Darwin Kernel Version 13.0.0: Fri Dec 5 11:47:48 CST 2014; nightsuns:xnu/BUILD/obj//DEBUG_ARM_ARMPBA8 Kernel UUID: 7217F5C1-00D6-35B9-BC5E-DD3576C1DD60 System model name: Power Macintosh

System uptime in nanoseconds: 2114343000 Using serial KDP. Using serial KDP.

Waiting for remote debugger connection.

Waiting for remote debugger connection.

Please go to http://github.com/winocm/xnu to report this panic.

Please go to http://github.com/winocm/xnu to report this panic. qemu: terminating on signal 2 from pid 949

[b-man]

nightsuns,

It looks like you are trying to boot xnu with 1GB of ram. Currently the RealView-PB A8 port is only configured to support 512MB of ram. The version of GenericBooter that you used from here is also outdated (I'm working on fixing this). For now I would recommend using winocm's GenericBooter: https://github.com/winocm/GenericBooter-next.git

I also presume you are using the ramdisk that was supplied in the image posted on reddit. To take advantage of the kernel's current capabilities (and to avoid unnecessary issues) I'll supply you with a copy of my ramdisk which has been verified to work: https://www.dropbox.com/s/j5id402t2er59vh/ramdisk_new.dmg?dl=0

For the next day or two I'm going to work on updating the wiki to include a more comprehensive set of steps for getting the kernel up and running on both OSX and Linux build hosts. I'm also going to make a repo for the ramdisk so people won't need to muck around with obtaining one from obscure sources. :)

[b-man]

Another helpful tip: passing symbolicate_panics=1 to bootargs makes debugging crashes much, much easier ;)

[nightsuns]

@b-man: do you know how to could i debug the kernel under the qemu -s -S.

i'am using gdb-arm-apple-darwin to debug, i can set the breakpointer, but i could not to print the variable.

or is there another debug ways?

[b-man]

nightsuns,

Unfortunateley I don't have access to my computer atm as I have been traveling this past couple of days (in California atm). I should have it in a couple of days, and by that time I'll be able to investigate debugging. I know that the last time I tried using gdb with xnu's debug script it had trouble loading symbols.

Btw, I haven't forgotten about the wiki - I'll get that done when I can.

[DanielKristofKiss]

hi all, Figure out the flow was tricky so I created a simple repo and makefile that executes the workflow that I think it is :) https://github.com/DanielKristofKiss/darwin-on-arm ( only MAC yet) BTW I ran into the same? hang issue on qemu.

used to with vmware and gdb the X86 version of the mack_kernel was debuggable nicely. now gdb-arm.. won't understand the debug symbols in mach_kernel maybe because it is compiled with clang, so lldb would be an option. qemu.. -s -S lldb mach_kernel (lldb) gdb-remote localhost:1234 (lldb) c

seems working but the breakpoint did not work for me.

BR, Daniel

[rzhikharevich]

I have a similiar problem.

[DanielKristofKiss]

hi, i have figured out the issue. libkern/gen/OSDebug.cpp:195 OSBacktrace function causes the data abort exception by storing to the address 0x00000003. Workaround: https://github.com/DanielKristofKiss/xnu/commit/d2f2a725935f676f8215b6b06b3b5f55d90d135a

with this simple change i was able to boot up in qemu.

how to debug: ( nightmare ) you need lldb,arm-none-eabi-gdb,qemu.

1. start qemu with -s -S options.
2. arm-none-eabi-gdb target remote localhost:1234
3. lldb .../mach_kernel.sys I have used lldb to look up addressed and symbols image lookup --address 0x804f4f2e image lookup --symbol fleh_dataabt etc. and use these value in GDB as break *0x804f4f2e

so no symbols in GDB just pure assembly ( layout reg,layout asm, focus cmd, focus asm are useful )

I have update my repo with the consistent set of stuff.

[b-man]

Hello all, I've finally got my computer again (took a bit longer than expected) and I've resumed work.

For those of you who are building on linux, I've finally put together a proper SDK framework to replace xnu-deps-linux and the chroot environment. This SDK framework has been designed with the intent of being useful for building both the kernel and the yet-to-be-made userspace. You can grab a prebuilt deb package for this new framework from here: https://www.dropbox.com/s/ynxq2zrocb43ehx/darwin-sdk_1.0_amd64.deb?dl=0 The sources for this package are available in the darwin-sdk repository.

I'll also be updating xnu's build system to reflect these changes, which should be done shortly.

And I'll also start work on the wiki tonight. :)

and DanielKristofKiss,

Thank you very much for investigating the debugging problem and for discovering that nasty bug. If you send a pull request I can get that fix merged in the main tree.

Edit: haha, helps to read. :P I'll see what I can do to create a properfix for that bug. But again, thanks for finding the problem.

[b-man]

Migeration to darwin-sdk from xnu-deps-linux is complete. For anyone building on linux, you will need to upgrade to the darwin sdk if you wish to take advantage of any further changes from now on.

[DanielKristofKiss]

hi all, i have solved today the gdb issue so from now it can be used for debugging with symbols and in any frontend (like eclipse). you can grab the source from here: https://github.com/DanielKristofKiss/gdb

I think it could be compiled on linux as well out of box.

[b-man]

rzhikharevich,

I've implemented what should hopefully be a proper fix for OSBacktrace and I've verified that it works on my side (via qemu), could you let me know if it is working on your side? Thanks.

[rzhikharevich]

b-man, I got this: make[6]: *\ No rule to make target /Users/roman/Desktop/iOS/xnu/osfmk/arm/cpufunc_armv7.h', needed bypmap.o'. Stop.

There's really no such header there.

[rzhikharevich]

I removed all my sources and recloned it. Now compiles successfully. It boots on iPhone 4 now.

[rzhikharevich]

It tried it with your ramdisk. It stucks on "Tuning kernel parameters", is it normal?

[b-man]

rzhikharevich,

Hmm, try commenting out these two lines in /etc/rc.boot inside the ramdisk and see what results you get: sysctl -w security.mac.proc_enforce=0 > /dev/null sysctl -w security.mac.vnode_enforce=0 > /dev/null

[rzhikharevich]

b-man, sorry for the delay, I was on holidays. I have commented it and hostname setting out. Now boots successfully until the "login:" prompt. Is it possible for someone in future to write a Camera Connection Kit driver for the winocm's kernel port for using USB keyboards with it?

[rzhikharevich]

I have added "ls /dev" to the boot script. Seems like it doesn't have disk0. It needs a NAND driver, right?

[b-man]

rzhikharevich,

No problem, hope you had a good break. :) It looks like this boot hang bug is also present on the BeagleBone Black I've recently acquired. I'll try to investigate this problem the next time I have some free time (school is starting for me next week). As for your first question, I'm sure it's definitely possible; it's just a matter of whether or not someone will be willing to put in the time to write such a driver. For your second question, yes; if the ramdisk was booted from a physical device such as NAND flash or an mmc card, it would be presented as a 'disk0' device. However since the entire ramdisk is loaded into ram at startup by the bootloader, it would be presented as a 'md0' (memory device 0) device. This is why rd=md0 is passed in bootargs before the bootloader passes control to the kernel.

[cdickman]

b-man,

very close...

qemu-system-arm -machine realview-pb-a8 -m 512 -kernel GenericBooter-next/uImage -append "rd=md0 debug=0x16e serial=3 -v symbolicate_panics=1" -serial stdio -nographic

Added memory device md0/rmd0 (02000000/0D000000) at 00000000808B3000 for 0000000001800000 BSD root: md0, major 2, minor 0 MAC Framework enabling multilabel support: root_device -> / (hfs) MAC Framework enabling multilabel support: -> /dev (devfs) ml_static_mfree: Released 0x167 pages at VA 0x8074c000, size:0x166b44, last ppn: 0x708b2 vm_map_pmap_is_empty(0xc0309f10,0x8074c000,0x808b3000): page 460620 at 0x8074c000 panic(cpu 0 caller 0x80032787): /home/ubuntu/Projects/DarwinARM/Work/xnu/osfmk/vm/vm_map.c:5227 Assertion failed: vm_map_pmap_is_empty(map, entry->vme_start, entry->vme_end) Debugger called: Debugger called: Backtrace (CPU 0), Frame : Return Address 0xca75b9e8 : 0x800328d5 mach_kernel : _panic + 0x125 0xca75ba18 : 0x80032787 mach_kernel : _Assert + 0x5f 0xca75ba40 : 0x800b242d mach_kernel : _vm_map_delete + 0x8e1 0xca75bb88 : 0x800b33fd mach_kernel : _vm_map_enter + 0x625 0xca75bd78 : 0x800b532b mach_kernel : _vm_map_enter_mem_object + 0xb47 0xca75bea8 : 0x80504ae7 mach_kernel : __ZN6OSKext19removeKextBootstrapEv + 0x28f 0xca75bf7c : 0x80525a51 mach_kernel : _OSKextRemoveKextBootstrap + 0x11 0xca75bf8c : 0x800527b7 mach_kernel : _kernel_bootstrap_thread + 0x10b 0xca75bfb4 : 0x80128b1c mach_kernel : _Call_continuation + 0x1c can't perform kext scan: no kext summary BSD process name corresponding to current thread: Unknown Boot args: rd=md0 debug=0x16e serial=3 -v symbolicate_panics=1

Mac OS version: Not yet set

Kernel version: Darwin Kernel Version 13.0.0: Thu Sep 10 20:52:58 UTC 2015; ubuntu:xnu/BUILD/obj//DEBUG_ARM_ARMPBA8 Kernel UUID: 8905EC60-D81C-36F8-91CE-1C6A7ABE2694 System model name: Power Macintosh

System uptime in nanoseconds: 2209483000 Using serial KDP. Using serial KDP. Waiting for remote debugger connection. Waiting for remote debugger connection. Please go to http://github.com/winocm/xnu to report this panic. Please go to http://github.com/winocm/xnu to report this panic. (qemu)

Any thoughts? Tried many different Ramdisks, both GenericBoot and -next.

[ghost]

By now everyone will have heard about Swift’s release to open source.

http://www.apple.com/pr/library/2015/12/03Apple-Releases-Swift-as-Open-Source.html http://www.apple.com/pr/library/2015/12/03Apple-Releases-Swift-as-Open-Source.html

https://swift.org https://swift.org/

https://github.com/apple/swift https://github.com/apple/swift

However, some may not yet have heard about the Swift Core Libraries project.

https://swift.org/core-libraries/#libdispatch https://swift.org/core-libraries/#libdispatch

https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-foundation

My question is how close this project comes to replicating the functionality of Darwin.

I’m guessing that any attempt to reimplement XNU in Swift is currently experimental, and being undertaken (if at all) primarily for what the effort can contribute to the development of the language, although, for the long term, the writing would appear to be on the wall pointing to that eventually happening.

Thoughts?

-jp

[androidisbest]

I am facing an issue very similar to @nightsuns and @cdickman . Please help me. I want to successfully boot and be able to use this kernel for educational purpose.

[androidisbest]

@b-man I am facing an issue very similar to @nightsuns and @cdickman . Please help me. I want to successfully boot and be able to use this kernel for educational purpose.

[b-man]

Hello @androidisbest Try commenting out the call to OSKextRemoveKextBootstrap under kernel_bootstrap_thread in osfmk/kern/startup.c.

There was a bug in OSKext::removeKextBootstrap that I thought I had fixed, but apparently it is still broken. Unfortunately I haven't had time to continue to work on these problems due to school.

[androidisbest]

Hey @b-man , Thanks for your quick reply. I tried commenting out the said line, but I am still facing the same issue. Please help me.

Following is the serial stdio output on my terminal:

Filling vm_pages with pattern: 0xdeb8f177 [ASID configuration start] All ASID/asids enabled: real_ncpus: 1, pmap_asid_ncpus: 1 Scheduler: Default of traditional PE_RealView: decrementer frequency = 5000 PE_RealView: RealView Timer initialized, Timer value 4795 rtclock_bus_configure: Configuring RTCLOCK... [RTCLOCK] Frequency = 1.000000MHz, cvtt2n = 000003E8.00000000, cvtn2t = 00000000.00418937 Initializing serial KDP Kernel boot args: '' PE_init_iokit: starting IOKit now! COLOR video console at 0xc0007000 (1024x768x32) bsd_autoconf: calling kminit

[androidisbest]

@b-man Also below is some more output if that is gonna help in any way in debugging..some issue with vm_map.c, assertion failure issue with vm_map_pmap_is_empty

ml_static_mfree: Released 0x167 pages at VA 0x8074b000, size:0x166970, last ppn: 0x708b1 vm_map_pmap_is_empty(0xc0309f10,0x8074b000,0x808b2000): page 460619 at 0x8074b000 panic(cpu 0 caller 0x8003276f): Projects/DarwinARM/Work/xnu/osfmk/vm/vm_map.c:5227 Assertion failed: vm_map_pmap_is_empty(map, entry->vme_start, entry->vme_end) Debugger called: Debugger called: Backtrace (CPU 0), Frame : Return Address 0xca75b9e8 : 0x800328bd mach_kernel : _panic + 0x125 0xca75ba18 : 0x8003276f mach_kernel : _Assert + 0x5f 0xca75ba40 : 0x800b23e9 mach_kernel : _vm_map_delete + 0x8e1 0xca75bb88 : 0x800b33b9 mach_kernel : _vm_map_enter + 0x625 0xca75bd78 : 0x800b52e7 mach_kernel : _vm_map_enter_mem_object + 0xb47 0xca75bea8 : 0x80504ae7 mach_kernel : __ZN6OSKext19removeKextBootstrapEv + 0x28f 0xca75bf7c : 0x8052581d mach_kernel : _OSKextRemoveKextBootstrap + 0x11 0xca75bf8c : 0x80052773 mach_kernel : _kernel_bootstrap_thread + 0x10b 0xca75bfb4 : 0x80128acc mach_kernel : _Call_continuation + 0x1c can't perform kext scan: no kext summary BSD process name corresponding to current thread: Unknown Boot args: rd=md0 debug=0x16e serial=3 -v symbolicate_panics=1

Mac OS version: Not yet set

Kernel version: Darwin Kernel Version 13.0.0: Sun Apr 17 20:54:20 IST 2016; indi:xnu/BUILD/obj//DEBUG_ARM_ARMPBA8 Kernel UUID: E2EA9AE7-CC74-3DC9-AF44-063CE7F605A8 System model name: Power Macintosh

System uptime in nanoseconds: 2192507000 Using serial KDP. Using serial KDP.

Waiting for remote debugger connection.

Waiting for remote debugger connection.

Please go to http://github.com/winocm/xnu to report this panic.

Please go to http://github.com/winocm/xnu to report this panic.

[androidisbest]

Ok after digging deep into the code late in the night after my office with my eyes almost dying to close, I commented out the assert statement in osfmk/vm/vm_map.c at line 5227 to see if that is gonna take me any where further and to my surprise I was successfully able to login with root and shell came up. I am still not sure why that assertion was failing even though when I dug deep and found out that the macro MACHINE_PMAP_IS_EMPTY is set as 1, so it must always do this-> return pmap_is_empty(map->pmap, start, end); which is this

boolean_t pmap_is_empty( pmap_t pmap, vm_map_offset_t va_start, vm_map_offset_t va_end) { vm_map_offset_t offset; ppnum_t phys_page;

if (pmap == PMAP_NULL) {
    return TRUE;
}

/*
 * Check the resident page count
 * - if it's zero, the pmap is completely empty.
 * This short-circuit test prevents a virtual address scan which is
 * painfully slow for 64-bit spaces.
 * This assumes the count is correct
 * .. the debug kernel ought to be checking perhaps by page table walk.
 */
if (pmap->stats.resident_count == 0)
    return TRUE;

for (offset = va_start;
     offset < va_end;
     offset += PAGE_SIZE_64) {
    phys_page = pmap_find_phys(pmap, offset);
    if (phys_page) {
        if (pmap != kernel_pmap &&
            pmap->pm_task_map == TASK_MAP_32BIT &&
            offset >= HIGH_MEM_BASE) {
            /*
             * The "high_shared_pde" is used to share
             * the entire top-most 2MB of address space
             * between the kernel and all 32-bit tasks.
             * So none of this can be removed from 32-bit
             * tasks.
             * Let's pretend there's nothing up
             * there...
             */
            return TRUE;
        }
        kprintf("pmap_is_empty(%p,0x%llx,0x%llx): "
            "page %d at 0x%llx\n",
            pmap, va_start, va_end, phys_page, offset);
        return FALSE;
    }
}

return TRUE;

}

which will essentially return true

Anyways let me know if you come up with proper solution I know for know this is not a proper fix, but I am happy I could boot it up somehow. LoL..And a big thanks to @winocm for doing all this for people like me. What a pure genius! Let me know how can I be involved in this project @winocm .