On Tue, Jan 29, 2008 at 09:25:59PM -0500, david bone wrote: > Concerning: Is __1cCbp6F_v_ (bp()) getting called in all threads that > are spawned? > This is only called from main() once. The dynamic threads that are > created afterwards have no knowledge of this global function. > The function was created as a starting point within the main function > to lower the copious tracings for my bird-eye-view to my problem.
That's why other threads aren't showing up in your traced view: you're using a thread local variable (self->...) as a predicate. > Concerning absolute addressing: > I still don't know how to accomplish this though the Dtrace doc > mentions that it can be done but without an example. I understand > that a probe name left blank means trace the instructions. Using a > module:function:offset makes the probe specific. My attempt is due to > the mangled names of my c++ code and templates etc. Grabbing an > absolute address from dbx out-of-the-debugger of sunstudio 12 seemed > a lot easier than wrestling with the mangled name and possibly its > mangled module etc. You can trace this by doing pid<pid>::-:<hex-address>. But be careful! An incorrectly aligned address can cause your application to crash. > Adam, how would u go about declaring such a pid probe given 0x12345 > as an absolute address within the process? Those were my attempts to > get it going. > > Concerning Attempt 3: echo > __1cGyacco2GParserOget_next_token6M_pn0AMCAbs_lr1_sym__::dis | mdb -p > pid > >It looks like there's likely no instruction at offset 0x291; how > >did you > >get that address? > > > The address was obtained using dbx from sunstudio12. Please see the > attachment `disassembly` showing the complete disassembled code for > the get_next_token function. Below is the extracted disassembled > instruction probed on. > __1cGyacco2GParserOget_next_token6M_pn0AMCAbs_lr1_sym__+0x291: > movl $0x0,-0x24(%rbp) > Unfortunately the instruction exists. Here's your request piped thru > mdb. Curious. I'm surprised that it's not letting you instrument that instruction. Show me this output: dtrace -l -n pid<pid>::__1cGyacco2GParserOget_next_token6M_pn0AMCAbs_lr1_sym__: > Yup. The `4.log` attachment from previous email shows the threads > being spawned but no probe firings to the individual threads. > Using mdb there are 3 lwps 1 for the process and 2 spawned threads. Again, this is because your program is not written to record the information you apparently want to trace. > As this is my 2nd week at dtrace-mdb familiarization i now am madly > reading while commuting by train the Solaris Internals book so that i > can be more intimate to the lpw environment with stored regs. my gut > feeling is the lwp 3's registers take on lpw 2 regs. I'm hoping to > use Dtrace to refine my own debug prodding to conclude why the bug. You might want to take a look at this presentation: http://blogs.sun.com/ahl/entry/dtrace_boot_camp - ahl -- Adam Leventhal, Fishworks http://blogs.sun.com/ahl _______________________________________________ dtrace-discuss mailing list [email protected]
