As has been previously stated, it''s pretty great to see the DTrace port
to
Mac OS X... if for no other reason than it affords me the opportunity to
_submit_ bugs rather than being responsible for fixing them ;-)
If I use a uintptr_t in the prototype for a USDT probe, I get an error like
this:
---8<---
$ gcc -o main main.c
error: Could not compile reconstructed dtrace script:
typedef int uintptr_t;
provider test {
probe stuff(uintptr_t);
};
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider test provider
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider test module
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider test function
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider test name
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider test args
ld: error creating dtrace DOF section
collect2: ld returned 1 exit status
---8<---
(By the way, that''s pretty cute how you reconstruct the script and
then,
presumably, feed it back through the D compiler in libdtrace)
If I change the uintptr_t to an unsigned long, things work fine. Here''s
the test case:
---8<--- provider.d ---8<---
provider test {
probe stuff(uintptr_t);
};
---8<--- provider.d ---8<---
---8<--- main.c ---8<---
typedef long uintptr_t;
#include "provider.h"
int
main(int argc, char **argv)
{
TEST_STUFF(7);
return (0);
}
---8<--- main.c ---8<---
How should we submit bugs against the Apple implementation of DTrace? If
you''d like to add a test to the DTrace test suite that would have
caught
this, feel free to submit the patch.
Adam
--
Adam Leventhal, FishWorks http://blogs.sun.com/ahl
At 9:30 -0700 27/10/07, Adam Leventhal wrote:>How should we submit bugs against the Apple implementation of DTrace?In general, anyone can submit a bug against anything that Apple ships by following the instructions on the following page. <http://developer.apple.com/bugreporter/> I don''t know if Apple''s DTrace team has special channels for DTrace-specific bugs. Perhaps Steve Peters can fill us all in. Regardless, IMHO it''s a good idea to file the bug using the Bug Reporting page and then shop around the bug number. This has a couple of advantages: o You can check on the status of your bug. The status information that you get is kinda limited, but it''s better than nothing. o Within Apple it makes for a single, well documented point of contact for the bug. Oftentimes a bug is ''well known'', but we don''t fix it because it never made it on to the official radar. Share and Enjoy -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
On Mon, Oct 29, 2007 at 03:13:38PM +0100, Quinn wrote:> At 9:30 -0700 27/10/07, Adam Leventhal wrote: > >How should we submit bugs against the Apple implementation of DTrace? > > In general, anyone can submit a bug against anything that Apple ships > by following the instructions on the following page. > > <http://developer.apple.com/bugreporter/>Thanks. I''ve followed the following bug: 5565198 ld(1) fails with DTrace providers that use certain types - ahl -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
On Oct 27, 2007, at 9:30 AM, Adam Leventhal wrote:> As has been previously stated, it''s pretty great to see the DTrace > port to > Mac OS X... if for no other reason than it affords me the > opportunity to > _submit_ bugs rather than being responsible for fixing them ;-) > > If I use a uintptr_t in the prototype for a USDT probe, I get an > error like > this:This is <rdar://problem/5194316>. The underlying cause is the "D" CTF container. It defines a bunch of default types, which are not considered "base" types. The script / linker magic decides that these types need to be encoded for the script reconstruction. When the script is reconstructed, we don''t expect to know about these types, but the "D" CTF container is always defined, and so dtrace believes we''re trying to redefine a known type. James M
James McIlree wrote:> On Oct 27, 2007, at 9:30 AM, Adam Leventhal wrote: > > >> As has been previously stated, it''s pretty great to see the DTrace >> port to >> Mac OS X... if for no other reason than it affords me the >> opportunity to >> _submit_ bugs rather than being responsible for fixing them ;-) >> >> If I use a uintptr_t in the prototype for a USDT probe, I get an >> error like >> this: >> > > This is <rdar://problem/5194316>. The underlying cause is the > "D" CTF container. It defines a bunch of default types, which are not > considered "base" types. The script / linker magic decides that these > types need to be encoded for the script reconstruction. When the script > is reconstructed, we don''t expect to know about these types, but the > "D" CTF container is always defined, and so dtrace believes we''re > trying to redefine a known type. >Has this bug been fixed in the latest Mac OS X update? -Robert
On Jun 25, 2008, at 12:45 PM, Robert Lor wrote:> James McIlree wrote: >> On Oct 27, 2007, at 9:30 AM, Adam Leventhal wrote: >> >> >>> As has been previously stated, it''s pretty great to see the >>> DTrace port to >>> Mac OS X... if for no other reason than it affords me the >>> opportunity to >>> _submit_ bugs rather than being responsible for fixing them ;-) >>> >>> If I use a uintptr_t in the prototype for a USDT probe, I get an >>> error like >>> this: >>> >> >> This is <rdar://problem/5194316>. The underlying cause is the >> "D" CTF container. It defines a bunch of default types, which are not >> considered "base" types. The script / linker magic decides that these >> types need to be encoded for the script reconstruction. When the >> script >> is reconstructed, we don''t expect to know about these types, but the >> "D" CTF container is always defined, and so dtrace believes we''re >> trying to redefine a known type. >> > > Has this bug been fixed in the latest Mac OS X update?This has not been fixed in 10.5.3. I can''t really comment on when it will be fixed, but in general I would hazard a guess that this doesn''t rise to the level of impact that would allow it to be included with a 10.x.x release. I''ve been wrong before, YMMV, not recommended for use by humans, and all the other usual disclaimers apply. James M
Hello,> I can''t really comment on when it will be fixed, but in general I would hazard a guess > that this doesn''t rise to the level of impact that would allow it to > be included with a 10.x.xrelease. I''ve been wrong before, YMMV, notOdd, under 10.5.3 I can''t get ''string'' to work either, would that increase severity, or am I doing something entirely wrong? (char* works, with string copying inside dtrace): ash-3.2# make dtrace -h -s a.d cc -I/tmp/dtr/dtrace-48/head/ -o a a.c In file included from a.c:3: a.h:28: warning: parameter names (without types) in function declaration error: Could not compile reconstructed dtrace script: typedef int string; provider a { probe log__something(string); }; #pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider a provider #pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider a module #pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider a function #pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider a name #pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider a args ld: error creating dtrace DOF section collect2: ld returned 1 exit status make: *** [a] Error 1 bash-3.2# cat a.c #include <dtrace.h> #include "a.h" main(){ A_LOG_SOMETHING("yay"); } bash-3.2# cat a.d provider a { probe log__something(string); }; -- This message posted from opensolaris.org
On Jul 1, 2008, at 9:16 PM, Domas Mituzas wrote:> Hello, > >> I can''t really comment on when it will be fixed, but in general I >> would hazard a guess >> that this doesn''t rise to the level of impact that would allow it to >> be included with a 10.x.xrelease. I''ve been wrong before, YMMV, not > > Odd, under 10.5.3 I can''t get ''string'' to work either, would that > increase severity, or am I doing something entirely wrong? (char* > works, with string copying inside dtrace):String is a ''D'' type, not a C type. Long story short, you want to use char*, not string. James M
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 2. Lack of -G makes various software not working. Both MySQL and PECL''s dtrace use it, instead of relying on generated .h files. 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. Long story short, I started playing with dtrace few hours ago :) Domas -- This message posted from opensolaris.org
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; > #endifI 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
Andreas Färber
2008-Jul-04 21:21 UTC
[dtrace-discuss] dtrace -G (was: Mac OS X 10.5 USDT bug)
Am 02.07.2008 um 08:22 schrieb James McIlree:> On Jul 1, 2008, at 10:57 PM, Domas Mituzas wrote: > >> 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.To add to that debate, I recently added USDT probes to the Mono runtime (http://www.mono-project.com). On Mac OS X, this was really easy. The dtrace -G for Solaris however does not play nice with GNU automake and libtool. Thus, I would rather prefer if Sun would drop dtrace -G like Apple did. But since that is unlikely to happen, it would be nice if Sun/Apple could contribute support for dtrace -G to those relatively common open source build tools, to facilitate adoption of DTrace. The problem is that the .o files to pass to dtrace -G are hidden either behind .lo files pointing to PIC and non-PIC .o files, or in .a files hidden behind a .la file. Further problems arise from the coexistence of PIC and non-PIC versions of the same object file and the usage patterns of the .la libraries (object files might be shared by multiple .la libraries and/or executables, so the original .o files can''t be modified or subsequent builds of other components would break for non- no-op dtrace -G). I came up with this dirty hack: http://anonsvn.mono-project.com/viewcvs/trunk/mono/dtrace-prelink.sh?view=markup A clean solution is to either drop dtrace -G on every platform or to add proper tool support for dtrace -G. I inquired with the libtool developers and they would be interested in patches, but I''m still pretty lost as to how to go about that myself. Andreas
Adam Leventhal
2008-Jul-10 08:32 UTC
[dtrace-discuss] dtrace -G (was: Mac OS X 10.5 USDT bug)
On Jul 4, 2008, at 2:21 PM, Andreas F?rber wrote:>> 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. > > To add to that debate, I recently added USDT probes to the Mono > runtime (http://www.mono-project.com). On Mac OS X, this was really > easy. The dtrace -G for Solaris however does not play nice with GNU > automake and libtool. Thus, I would rather prefer if Sun would drop > dtrace -G like Apple did.I realize that having an additional step can be a pain, but there''s additional information that we intend to add to the provider definition file that the -G option lets us do. That said, we some investigation into adding an option to the linker so while we''re not going to get rid of the .d file, we may make it possible to pass in the appropriate .d file to the final linker invocation. This solves a few problems including IPO and dealing with archives (.a libraries). Adam -- Adam Leventhal, Fishworks http://blogs.sun.com/ahl