homepage

On Wed, Nov 12, 2008 at 9:31 PM, Skip Montanaro <report@bugs.python.org> wrote:
> I see the reference to Apple in your original post, but can't find anything
> related to dtrace & python starting from the URL you gave. Do you have
> something more specific?
http://www.opensource.apple.com/darwinsource/10.5.5/python-30.1.2/
That isn't Python 3.0, that's what I guess they call Python "Apple
Version 30"? Anyways, it's their Python 2.5.1 and their "patches"
against it are actually ed scripts, contained in fix/
That's where my patch comes from, it's just changing the .ed scripts
to a patch and applying it against 2.6
> At this point Jeff's code does a fair bit more than simply tracing the
> CALL_FUNCTION opcode but needs some work with the other CALL_FUNCTION_*
> opodes. It also has some obmalloc tracing which I've not yet tested. I
> would have thought Apple would more heavily instrument the interpreter than
> it appears they have.
Sun has released a patch against DTrace that probes more than just
function calls also. At least, it provides line number and some other
information, http://cvs.opensolaris.org/source/xref//jds/spec-files/trunk/patches/Python-07-dtrace.diff
I couldn't figure out why it broke the compile on OS X though, and
could only get it working on Solaris.
There's another problem (I think) with DTrace probes ... if the Apple
guys release Apple-Probe-Python.d and the Sun guys release
Sun-Probe-Python.d (just two scripts) and we setup our probes
differently, one or both will fail (because one may expect a probe for
foo while another expects a probe for bar). Kind of sucks,
considering Sun was first and Apple chose to probe Python differently.
 Now we have to pick one or make a 3rd... I could be very mistaken
here, though.