Re: dtrace on kexts?
Re: dtrace on kexts?
- Subject: Re: dtrace on kexts?
- From: Terry Lambert <email@hidden>
- Date: Wed, 4 Mar 2009 17:14:11 -0800
On Mar 4, 2009, at 4:58 PM, Andrew Gallatin wrote:
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)
You are basically recreating the ordinal inde with all of the types
that are already ordinally defined in the existing Sun code, plus
yours. This works for a single additional module, but not for
multiple modules that have shared types not known to the kernel.
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.
Knowing how to instrument the function preamble to cause an FBT probe
to be inserted requires either knowing the location of the start of
the function because you have a symbol in hand, and then the
instructions matching the known preamble types supported for FBT
probing, OR it requires the ability to perform reachability analysis
statically to determine what's code and what's not code, and then
what's a target of a call instruction (or n the case of a tail call
optimization, a jump target that's a function entry rather than a
normal jump target) to analytically find the function entry points.
We in fact do reachability analysis for PPC code, which lets the jump
tables be identified (they aren't, in Intel code, as of yet), but that
information is only used to deal with not being overly conservative
when it comes to code-that-looks-like-data, not to put probes into FBT
code without symbols.
Again, to know the locations of these entry points by symbol, even if
not by symbol name, requires minimally the address portion of the
symbol table from the Dwarf information associated with the KEXT. To
do that requires that we either have an exterior mechanism for
locating the object file that was loaded in order to instance a KEXT,
which could potentially not exist for a lot of reasons, and which is
typically only recorded in user space by kextd (if they exist at all,
rather than as, for example, tftp files on a server some place). Then
you have to trust the user space process to push the probe location
data down to /dev/dtrace for these kernel code values, with some sort
of rendezvous finding the base load address actually used for the
image. Either initially loading or later pushing this information to
the FBT code so it can know about it requires KVA for mapping the
location information to make it visible to FBT.
At any rate, I'm glad you're aware of the problem and are trying
to fix it!
It's one of the most requested features for dtrace internally at Apple.
It's a hard problem to resolve, and we've thought about it a lot,
including consulting with the Sun folks on the issue. It's unlikely
to be resolved in a 32 bit kernel with video driver mappings in kernel
space.
You can actually build you own kernel with the driver statically
linked in, which would let you trace things that way, bbut you have to
go out of your way to do it.
-- Terry
_______________________________________________
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