[EMAIL PROTECTED] wrote: >> My wish list: (not strictly DTrace limitations, but related) >> >> 1. Since the pid provider takes instruction addresses, I >> wish that there was a reliable and easy method to >> determine the line number in the source given the >> address and vice versa. The dbx program does this, so >> it must be possible. In fact, the right compilation >> and linker flags, maybe DTrace could do this right in >> the pid provider! > > There's a one to many mapping, so which instruction would you want to > instrument? (the compiler will completely rearrange the instruction > stream).
I would be happy with any of them. First would probably be best. Any would work for me too. > >> 2. Comprehensive data symbol information in CTF for the >> kernel. Right now, DTrace cannot find any of the symbols >> that are defined in .s files in the kernel. Even if you >> provide the address manually, it does not know the data >> type. So, this wish is two-fold. One, give the user a >> way to manually tell DTrace a symbol address and data >> type and let it treat this symbol as a first class >> symbol from then on. And two, add some kind of macro >> to the assembler so it would generate whatever it needs >> to in the resulting object files to allow the variables >> in .s files to play in the CTF game. > > > For which kernel variables is this a limitation? > > As there's a fairly easy work around: define all globals in a .c file, > I would not necessarily see this as an important restriction. 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. > > Casper > > _______________________________________________ > dtrace-discuss mailing list > [email protected] -- 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]
