Hi Dave, All of that information was discarded in favor of CTF data. In fact, apptrace now just uses CTF data to symbolically print function arguments. It was always the plan to have DTrace use this user-land CTF data.
Adam On Jan 21, 2009, at 10:26 AM, David Collier-Brown wrote: > My leaky memory says we moved entry-point > into some form of debug record in the > standard libraries, circa Solaris 8/9. > > Before that, my group maintained text files that > listed all the entry-points and their parameters for > libraries like libc.so, so that we could print > out parameter values in apptrace(8). > > There's a (small) chance the records are complete enough > that dtrace could use the debug records from the > system libraries, and in principle any library with > the right information available. > > I *don't* know whether they are complete enough: that > was done after my time in the ABI team. > > --dave > > > > Jon Haslam <jonathan.has...@sun.com> wrote: >> Yes, having user-land type information would allow you >> to do what you want here. As I said, it's something we know >> users would like but it would be a piece of work to implement. > > > "P. Remek" <p.rem...@googlemail.com> asked: >>> First thing that crossed my mind: We provide application to our >>> customers >>> and we provide support for it. When we release new version there are > usually >>> issues reported by customer. After some time I've realized that >>> most of >>> the issues (let's say 50%) will appear (or let's say affect) >>> function's parameters >>> on some level of execution. Right now we have tracing macros >>> directly >>> compiled into our application for each function's return/exit which >>> logs function >>> parameters as well as function name. By observing it I am usually >>> able >>> to quickly locate >>> culprit of the issue. Problem is that we have to maintain all those >>> tracing macros >>> in the code. With dtrace I am able to get only function's name (as >>> it >>> is in ABI) >>> with one general "pid$1:::entry". As per my understanding there is >>> no >>> way to define >>> function parameters logging generally.I would need to let's say >>> include header file >>> with function's prototypes and manually create probe for each >>> function. To have >>> better idea there is an application which I have tried which does >>> similar thing on >>> windows platform: www.autodebug.com. >>> >>> Remek > > -- > David Collier-Brown | Always do right. This will gratify > Sun Microsystems, Toronto | some people and astonish the rest > dav...@sun.com | -- Mark Twain > cell: (647) 833-9377, bridge: (877) 385-4099 code: 506 9191# > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss@opensolaris.org -- Adam Leventhal, Fishworks http://blogs.sun.com/ahl _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
