> >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). > 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. Casper _______________________________________________ dtrace-discuss mailing list [email protected]
