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
[email protected]
