Breakpoints Not Working When Debugging in Xcode on a Voodoo Kernel Hackintosh

I recently built and OSx86 machine, but I had never actually tried doing any (native) development[0] on it as I had been using my MacBook for that purpose. Tonight I finally fired up Xcode on the new desktop, created an iPhone application, and found that my breakpoints, which were being correctly set and detected, were not ever actually being hit. It was as if they were being ignored completely.

After Googling around for some hints as to why this would happen, on a hunch I tried debugging a C application that targeted the OSx86 machine itself: same issue, no breakpoints were hit. My desktop and laptop have the exact same applications and tool chains, and the only real difference between the two machines from a software standpoint was the kernel. This led me to believe that the Voodoo kernel used on the desktop had some debugging issues. Doing a search on this confirmed my suspicion, as the Voodoo team has an open bug on this exact issue. Luckily, a few searches down, I also found a workaround that happens to fix the issue for Intel based machines.

When starting your system, enter the following as one of your boot flags:

std_dyld=1

From the voodoo kernel documention:

std_dyld= On-the-fly opcode patching requires an elaborate technique to patch dynamic libraries. Because of this, the kernel includes its own specialized copy of dyld, and chooses the best one depending on your CPU. Use this option to force the kernel to use standard dyld (pass value 1) or its specialized copy. (pass value 0), regardless of your CPU type. Note: AMD insta$s might fail to function if you specify this boot-flag!

While Googling, I saw numerous forum posts about this issue on OSx86 machines, with no one realizing there is a workaround. So hopefully this post matches enough keywords to save someone an hour or two of searching. :)

Edit/Note: If you are booting off a kernel on your EFI partition, make sure that it is named "mach_kernel" and that a copy of that exact kernel is available at /mach_kernel on your system partition. (I had issues with VMWare not working until I did this, and suspect it may cause issues with XCode too)

[0] I have been using it to do Android development, and have no issues debugging the Dalvik VM. But I am guessing the Dalvik VM on an emulator/device does not require the same low level kernel hooks on the host.

12 comments:

Even said...

Thank you very much for posting this. I had trouble with voodoo and breakpoints and thought there was something I did wrong. I will check it as soon as I come home - This proably saved me a lot of work.

Anonymous said...

Thank you very much too. It helped me a lot, AMD though. It works. :)

HaPpY said...
This comment has been removed by the author.
HaPpY said...

I just tried this and it worked perfectly. However it also required cpus=1 otherwise a kernel panic on boot ensued.

My kernel flags are now:
busratio=20 cpus=1 std_dyld=1

running iDeneb 1.4/Leopard 10.5.7 on eVGA x58/i7 920i

anyway thanks for the help :)

Daan said...

Thanks! Was mystified over my 'gdb internal error: virtual memory exhausted' messages until I found your post... Now I got it up and running again. :)

sedwo said...

I just installed the latest Voodoo kernel (Alpha3) which has the default 'std_dyld' enabled. So the breakpoints now work, but stepping through and over doesn't report very well.

Unlike other IDE's, I see the debugging focus move down a line when I step-over. But here, I get nothing, except:

Current language: auto; currently c++
Xcode could not locate source file: new_opv.cc (line: 34)
Xcode could not locate source file: new_opv.cc (line: 34)
Xcode could not locate source file: new_opv.cc (line: 34)
Current language: auto; currently objective-c
Warning: the current language does not match this frame.
Xcode could not locate source file: new_opv.cc (line: 34)
Xcode could not locate source file: new_opv.cc (line: 34)

Any ideas?

How well does your debugging work?

HaPpY said...

i have the same problem with breakpoints but i stopped worrying about it when i realized that c++ is fully supported. so im doing 99% of my iphone development in visual studio in windows instead :)

if you're planning on making games (likely using opengl) i highly recommend doing the same. just write a thin platform abstracting layer so you can easily swap system specific code.

this is also ideal if you want to port your app to other devices such as android.

Daan said...

@sedwo I got no problems with debugging in xCode using voodoo kernel v9.7 (the one which comes with iAtkos v7)

sedwo said...

@Daan, just tried the voodoo kernel v9.7 and it didn't improve things. :(

The breakpoint breaks properly, but step-over doesn't work well within the IDE. Same as before. :/

Anonymous said...

Thanks man. You have saved my life. Seriously !!

Oftenwrong Soong said...

Dude check out this link: Breakpoints not working in Xcode?. If you push "Run" to start your program, breakpoints will not work because your program is not running through the debugger. Xcode is flexible in that it lets you define breakpoints but doesn't necessarily run your program through the debugger. You get to choose whether to run it normally (Run), in which case breakpoints won't work, or to run it through the debugger (Debug) in which case the breakpoints should work fine.

Anonymous said...

Thanks Koush an Happy! Was about to throw in the towel and buy a mini for development but now I could hold off for a bit.

After adding 'std_dyld=1' I was getting a kernel panic. Then I saw the comment Happy posted about cpus=1 and my debugging now works flawlessly!

My current machine is a core 2 duo on a gigabyte MB. And my flags are "std_dyld=1 cpus=1 -v"