Slashdot Mirror
Apple Quietly Fixes DTrace
In January we discussed a blog entry revealing that Apple had "crippled" its DTrace port. As the author notes in a followup post, to say that DTrace had been "crippled" was at least overstated: "Unfortunately, most reactions seized on a headline paraphrasing a line of the post — albeit with the critical negation omitted." In an updated entry, the poster notes that Apple has made good (so we have too): "One issue was that timer based probes wouldn't fire if certain applications were actively executing (e.g. iTunes). This was evident both by counting periodic probe firings, and by the absence of certain applications when profiling. The good news is that Apple has (quietly) fixed the problem in Mac OS X 10.5.3."
Developer specific issues like this would certainly be fixed quickly under Linux, since it is a developer OS. On the other hand, usability issues that get fixed quickly under OS X, are often left to languor under Linux.
In both cases those features may never be fixed under Windows (or would be broken again after the next "Service Pack"
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
But that's exactly what Apple's done with their DTrace implementation. The notion of true systemic tracing was a bit too egalitarian for their classist sensibilities so they added this glob of lard into dtrace_probe() -- the heart of DTrace:
That's just sad. You shouldn't flash those numbers in public.
Its clear from the DTrace source from Apple that this is intentional. The OS has a "this app cannot be debugged" flag and they deliberatly made the decision that "cannot be debugged" == "cannot be DTraced"
Most likely they are trying to prevent tracing/debugging/reverse engineering of apps like iTunes and QuickTime that host ITMS DRM content.
It was apple-specific. They had a "don't debug me" flag that a process could set at startup (to protect DRM). But there was a bug in the interaction of these processes that could cause dtraced processes to take *forever*.
Care about electronic freedom? Consider donating to the EFF!
Surely you could just recompile dtrace for mac os x without the check though?
"Quietly" infers that the slashdot crowd should get credit, where no credit is due, as if our overwhelming numbers and sheer pressure forced Apple to change. Unfortunately, in the real world, we are such an insignificant demographic, that any changes are thus labelled as being done "quietly".
What did you want, a friggin' parade?
Jeez, give a fruit a break.
No, but I did throw granola at a deaf person once
Lifted from http://developer.apple.com/qa/qa2001/qa1118.html because I know no one will RTFA
Q: I'm trying to link my binary statically, but it's failing to link because it can't find 'crt0.o.' Why?
A: Static linking of user binaries is not supported on Mac OS X. Tying user binaries to the internal implementation of Mac OS X libraries and interfaces would limit our ability to update and enhance Mac OS X. Instead, dynamic linking is supported (linking against crt1.o automatically instead of looking for crt0.o, for example).
We strongly recommend that you consider the limitations of statically linking very carefully, and consider your customer and their needs, plus the long-term support you will need to provide. Apple provides support and attempts to insure complete compatibility through the published APIs, but cannot insure that compatibility in a statically linked project. Any change to Mac OS X, in a system update, security update, or major revision, may break statically linked code.
If your project absolutely must link statically and need crt0.o, you can get the Csu module from Darwin and try building crt0.o statically. Please bear in mind that you must then clearly specify to your customers the compatibility risks involved in installing a product that relies on statically linked code.
No, but I did throw granola at a deaf person once
There are of course system calls (both BSD-style and Mach-style ones), but they are undocumented and can change from one Mac OS X version to another (even between minor system updates). The reason is that Apple wants to have and keep full freedom in changing the systemuser space interface at any time it wants whenever that's convenient for whatever reason (performance, security, getting rid of legacy cruft,
So if you'd statically link a program, it would be linked to a particular libc version which in turn would use the system calls as they work on the particular version of Mac OS X this libc version was compiled for. The end result would be that your program would only be guaranteed to function correctly on that particular OS revision.
libc's interface on the other hand is kept backwards compatible between OS revisions, so as long as you dynamically link against it, your program will work fine on pretty much any OS version out there (except if you use APIs which didn't exist yet in older versions).
This is more or less the opposite case as on e.g. Linux, where glibc breaks binary compatibility every other full moon (so you need to distribute different binaries for different glibc versions if you want to link dynamically to it), but the kernel's system call interface is pretty much guaranteed to remain backwards compatible for a very long time (so statically linked binaries are generally much more portable across distributions â" the downside is that you then should link everything statically because installed dynamic libraries may rely on features provided by a newer glibc than the one you statically linked, and in case of e.g. a KDE or GNOME app you'd end up with immense binaries).
Donate free food here
Obviously DRM crackers are incapable of this level of ingenuity (if you live in cuckoo land that is..)
which is totally what she said