Adam,I appreciate your closing paragraph. As this is my very first time as Madona's song goes to `open source community` dialogue, I assumed as u were the only one that responded to my first call-for-help that possibly my request was too esoteric and i did not want to make graffiti out of my request to the others. So i'll also post the other private email with its attachments to the dtrace-discuss community after this email so they can bring-themselves-up-to-speed.
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.
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.
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 youThe 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.get that address?
__1cGyacco2GParserOget_next_token6M_pn0AMCAbs_lr1_sym__+0x291: movl $0x0,-0x24(%rbp)Unfortunately the instruction exists. Here's your request piped thru mdb.
disassembly
Description: Binary data
Attempt 4: You're instrumenting every offset probe in that function. Areyou sure that function is getting called?
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.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.
Dave On 29-Jan-08, at 1:10 PM, Adam Leventhal wrote:
On Mon, Jan 28, 2008 at 08:15:41PM -0500, david bone wrote:I've attached 3 files: 1) o2debug1.d --- dtrace file showing my pid function traces and its companion `4.log` file showing the output. I've commented inside the `d` file my objectives and observations. The `4.log` file shows the threads spawned etc but no tracing of their functions.Is __1cCbp6F_v_ (bp()) getting called in all threads that are spawned?2) o2debug2.d --- trying to set probe firing using absolute addressing. the `d` file has comments and the Dtrace compiler's error messages.Attempt 1: You're trying to enable the 0x64e00c offset probe in every function Attempt 2: You're trying to use the address as the module; that's just wrongAttempt 3: Please send me the disassembly output forecho __1cGyacco2GParserOget_next_token6M_pn0AMCAbs_lr1_sym__::dis | mdb -p pid It looks like there's likely no instruction at offset 0x291; how did youget that address?Attempt 4: You're instrumenting every offset probe in that function. Areyou sure that function is getting called?I thank u for your time.No problem. I'd appreciate it if you would post this sort of thing to thediscussion list so that other people can benefit from the response and perhaps help you out. Adam --Adam Leventhal, Fishworks http:// blogs.sun.com/ahl
_______________________________________________ dtrace-discuss mailing list [email protected]
