>> It it not generally possible to determine the the probe fires whether or not >> the thread is currently executing in leaf context. All symbolic translations >> happens in user-land after the fact for both ustack() and uaddr(). >> >> > I'm afraid you lost me. What does symbolic translation have to do with > detecting the presence of a stack frame? I could imagine it being possible to > stash this info in debug sections (at least for dwarf2), but I don't think > that's what you're referring to here.
Neither the symbol table nor stabs-like sections are available from the context in which the probe fires. > By 'leaf' I just meant 'the top of the user stack' (as in the analyzer's > 'leaf is' predicate) but maybe there's a more precise definition of leaf I > wasn't aware of? Yes, I understand what you mean. >> What we could do is have the ustack() action record %o7 as well and then >> figure out in user-land whether or not it's relevant. >> > Actually, I tried %o7 first, and it's pretty dodgy -- once a stack frame has > been created, it can hold anything. CC seems to use it a lot for bit-shifting > and as the target of JMPL. In contrast, %i7 is (nearly) always valid. In leaf-context, %o7 is all you have -- the %is and %ls belong to the previous frame. > Two changes, I think. BTW, is this a sparc-only issue or would it also affect > x86? This would apply for x86/x64 as well as SPARC. > http://wikis.sun.com/display/DTrace/Actions+and+Subroutines#ActionsandSubroutines-%7B%7Bustack%7D%7D, > needs something resembling: > > Limitations: Because ustack() must traverse stack frames to build its stack > trace, functions which do not establish a stack frame can lead to > unpredictable results. In particular > • Functions making tail calls will not appear because they tear down > their own stack frame before making the call. > • Except inside function entry probes, leaf functions which have not > (yet) established a stack frame sometimes prevent their caller from appearing > in the stack trace (e.g. foo -> bar -> baz will appear as foo -> baz). See > <link-to-note-at-profile-provider>. > > http://wikis.sun.com/display/DTrace/profile+Provider needs a new section at > the end (before 'Stability'): > > Limitations: > > ustack() only reports the caller of a leaf function if the latter has > established a stack frame. A leaf function is typically used to refer to one that doesn't establish a stack frame. > Otherwise, the caller's caller appears to call the leaf function (e.g. foo -> > bar -> baz will be repoted as foo -> baz). This behavior occurs because > dtrace has no way to determine whether the current top of stack has > established a frame or not. DTrace can avoid the problem with function entry > probes because they always fire before the target has established a stack > frame, and with the return address is in a known location, neither of which > is necessarily true in profile probe context. Close enough. Adam -- Adam Leventhal, Fishworks http://blogs.sun.com/ahl _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
