Re: dtrace on kexts?
Re: dtrace on kexts?
- Subject: Re: dtrace on kexts?
- From: Andrew Gallatin <email@hidden>
- Date: Wed, 04 Mar 2009 19:58:03 -0500
Terry Lambert wrote:
Sun deals with this by compiling everything in the same CTF space in
order to ensure the type format data is there; they get away with this
by compiling everything at once.
Everything does not need to be compiled at once on Solaris.
I compile my Solaris drivers with full dtrace (and mdb)
info by running this on the .o creation:
%.o: %.c
$(CC) $(CFLAGS) -c -o $@ $<
ctfconvert -i -g -L LABEL $@
And then this on the completed binary module:
myri10ge: $(OBJECTS)
$(LD) -dy -r -o $@ $(OBJECTS) -N misc/mac -N strmod/ip -N
misc/zmod
ctfmerge -g -L LABEL -o $@ $(OBJECTS)
The problem with doing this for Mac OS X for third part KEXTs at this
time is that the type information is by ordinal value of the type
definition as culled from the Dwarf debugging information, and it's a
flat ordinal space. This gives you two choices (both of which have been
discussed in detail with the Sun folks) of either duplicating the type
information and treating it as a separate per-KEXT tuple space, or
trying to find some way of having sub-spaces that are then used only for
per-KEXT information.
For right now, with the video drivers in there, there's simply not
enough KVA for a duplicated space in a 32 bit kernel.
The profile provider will definitely give you the EIP/RIP at the time
the profile probe fires, but translating that back into symbols will
take a debugger.
For what I was trying to do, even allowing the unsymboled hex addresses
to be used by fbt would have been immensely helpful, as I was only
trying to trace return values.
At any rate, I'm glad you're aware of the problem and are trying
to fix it!
Drew
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden