[EMAIL PROTECTED] wrote: > >> The fact that it should be easy to fix doesn't change the fact that it >> should be fixed. Which reminds me, DTrace doesn't read CTF info for >> user executables, right? If not, it should. > > > It's not necessarily "easy to fix". Easy to workaround, perhaps./ > > But you sidestep the more important question I asked: how big of a problem > is it really? How many variables are defined in .s files? > > Casper >
I don't know really. But it seems like all the ones I am ever interested in are. 8-) However, it seems to me to be an obvious extension. If I presume that CTF info was sufficiently useful to have been worth creating in the first place, and that new tools will be made that use the info, then allowing the assembly source files to play in that space is only logical. It seems like it would be relatively simple to add the info to the object files produced by the assembler. In fact, a quick look at some of the source files shows that much of the info is already there, apparently for the use of lint. -- blu There are two rules in life: Rule 1- Don't tell people everything you know ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom _______________________________________________ dtrace-discuss mailing list [email protected]
