On Jul 1, 2008, at 10:57 PM, Domas Mituzas wrote: > Helloes, > >> String is a 'D' type, not a C type. Long story short, you want to >> use char*, not string. > > Oki, thats what I thought - though now I have to use lots of > copyinstr()s. > > Interesting though, I ended up porting some dtrace hooks (in stuff > like php pecl's dtrace) from solaris to macosx. > > There were few problems: > > 1. dtrace.h defined GElf_Addr and GElf_Xword in #if > defined(__LP64__) and #elif defined(_LONGLONG_TYPE) sections - so on > 32-bit macosx it failed to work. > I just added: > #else > typedef unsigned long GElf_Addr; > typedef unsigned long GElf_Xword; > #endif
I filed <rdar://problem/6048996>. What are you doing that you need to #include dtrace.h ? > > > 2. Lack of -G makes various software not working. Both MySQL and > PECL's dtrace use it, instead of relying on generated .h files. This is the source of some debate between Adam and I :-). We're planning to add a -G no-op flag so builds don't fall over, but we have no plans to ever support the old DTRACE_PROBE macros. > 3. .d files for various Solaris-oriented stuff have 'string', I > guess it works as generated ELF - so I have to rewrite both > headers / provider definitions to have char*, for MacOSX compile. I have to admit, I'm stumped as to how this could ever work. Your C compiler should be unhappy about a missing type named "string". If you're using C++, your compilers should be REALLY unhappy. You mentioned above that by using char* you now have to use copyinstr(). That implies that on the Solaris side, somehow the string is being passed by value, but strings are, by nature, variable in size. I don't see how that works... James M _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org