In my ongoing quest to dump data from a struct in the pid provider, I was finally able to load up the convoluted set of .h files for this application, only to discover two things: 1. Dtrace takes a godawful long time to process include files. 2. It was a useless exercise anyway, because I am using the pid provider and the fbt provider simultaneously on a 64bit system with a 32 bit app. Since the includes are all in a LP64 context, most of the fields were wrong anyway. An interesting fact I discovered related to 1 above. When using the pid provider, dtrace grabs the process before compilation so that it can compile in the $target macro. However, because of the length of time it takes to do the includes, the process is dead for a very very long time. Not good for tracing race conditions. In order to remedy this, I decided to hand craft the struct definition alone and put that inline to the d script. To that end, I made a little c program that did the includes required, and then printed out the "sizeof(struct peer)" (peer is the name of the struct in this case). I then compiled and ran it in 32 bit mode to get the sizeof the struct, and then compiled and ran it in 64 bit mode to confirm that it was a different size. I then compiled it with -E to see what it looked like after all the preprocessing. I then proceeded replace all the field types with there 32bit specific equivalents, until I got what I thought should have been the right definitions. I confirmed this by compiling the result and noting that the sizeof of the 64 bit version printed the same number as the 32 bit version. I then moved the "struct peer" definition I had into a dscript and tried to compile and use the field names. It all seemed to work great, except I kept getting a syntax error in the middle of the struct. It turns out that one of the fields was named "status" and D was unhappy with this. Changing the name to "status1" made it happy again. So, my first question is what is the deal with the name status? My second question is was there a simpler way to do this? I mean does D have some nifty magic to compile some definitions in 32 bit model and some in 64? Could I have dumped the field info using some CTF tools? -- blu Remember when SOX compliant meant they were both the same color? ---------------------------------------------------------------------- Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
> In my ongoing quest to dump data from a struct in the pid provider, > I was finally able to load up the convoluted set of .h files for > this application, only to discover two things: > > 1. Dtrace takes a godawful long time to process include files.Yep, that''s my bad. Or rather, one of our many "punts" that I haven''t had time to go back and fix yet. Apologies for that.> 2. It was a useless exercise anyway, because I am using the > pid provider and the fbt provider simultaneously on a > 64bit system with a 32 bit app. Since the includes are all > in a LP64 context, most of the fields were wrong anyway.So it would be really helpful to me for you to describe specifically and post the question and script you''re trying to use here. One principle at the moment is that D has but a single data model, which makes the simultaneous kernel/user tracing tricky with respect to .h files. This will be improved when we can import user CTF, but I would like to understand your use case to help plan that. We also have the -32/-64 options to change the data model, but that only helps if you want to exclusively look at your user app.> ... > > I then proceeded replace all the field types with there 32bit > specific equivalents, until I got what I thought should have > been the right definitions. I confirmed this by compiling the > result and noting that the sizeof of the 64 bit version printed > the same number as the 32 bit version. > > I then moved the "struct peer" definition I had into a dscript > and tried to compile and use the field names. > > It all seemed to work great, except I kept getting a syntax > error in the middle of the struct. It turns out that one of > the fields was named "status" and D was unhappy with this. > Changing the name to "status1" made it happy again. > > So, my first question is what is the deal with the name status?Again, can you post or e-mail me the details? You may be running into an issue here with an typedef name conflict from a type in the kernel. I did some work to address this problem before S10 shipped, but I may have missed a corner case. E-mail the script and I''ll post what is going on.> My second question is was there a simpler way to do this? I mean > does D have some nifty magic to compile some definitions in > 32 bit model and some in 64? Could I have dumped the field info > using some CTF tools?I am working on the support for importing CTF directly into your D scripts, which solves many of these problems. At present you''ve got the best approach, but we''re well aware this isn''t good enough. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/