Anyone know why -G flag is not supported in the Dtrace port in Leopard? This makes the dtrace cmd in Leopard incompatible with that on Solaris, and it''s already causing problem with PostgreSQL. -Robert -------------- next part -------------- An embedded message was scrubbed... From: Lee Packham <lpackham at gmail.com> Subject: [BUGS] BUG #3699: Fails to compile DTrace Support Date: Fri, 26 Oct 2007 07:30:10 +0000 (GMT) Size: 6292 URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20071026/05b896ee/attachment.nws>
It''s especially odd that they''ve chosen to support the -h option, but not the -G option -- I''m not to what purpose one could put the generated header file. Perhaps the Apple folks could comment? Adam On Fri, Oct 26, 2007 at 10:27:25AM -0500, Robert Lor wrote:> Anyone know why -G flag is not supported in the Dtrace port in Leopard? This makes the dtrace cmd in Leopard incompatible with that on Solaris, and it''s already causing problem with PostgreSQL. > > -Robert> Date: Fri, 26 Oct 2007 07:30:10 +0000 (GMT) > From: Lee Packham <lpackham at gmail.com> > Subject: [BUGS] BUG #3699: Fails to compile DTrace Support > To: pgsql-bugs at postgresql.org > X-Mailing-List: pgsql-bugs > > > The following bug has been logged online: > > Bug reference: 3699 > Logged by: Lee Packham > Email address: lpackham at gmail.com > PostgreSQL version: 8.2.5 > Operating system: OSX Leopard > Description: Fails to compile DTrace Support > Details: > > I have built a patch to enable a working DTrace on OSX with Postgres 8.2.5. > Basically the problem is that the dtrace command on OSX doesn''t have the -G > parameter - so you have to use the newer -h method to produce a header file. > > > I have put the patch on my blog. > > http://leenux.org.uk/dtrace-patches/dtrace-with-postgres-on-osx > > Hope this is of use to you guys. > > Cheers, > > Lee Packham > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org> _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
On Oct 26, 2007, at 8:44 AM, Adam Leventhal wrote:> It''s especially odd that they''ve chosen to support the -h option, > but not the > -G option -- I''m not to what purpose one could put the generated > header file. > Perhaps the Apple folks could comment?The Mac OS X "dtrace -h" emits all the information required for successfully linking a USDT probe by the rest of the toolchain. On Mac OS X "dtrace -G" is superfluous. For historical reasons "-G" was disabled early on in the bring up. We''ll take a bug to re-introduce "- G" as a no-op with a warning message. See the section "BUILDING CODE CONTAINING USDT PROBES" in the Leopard dtrace(1) man page. Static probes work very nicely on Mac OS X (thank you!) A number of our frameworks ship with "Is Enabled" static probes in Leopard. SCP> > > Adam > > On Fri, Oct 26, 2007 at 10:27:25AM -0500, Robert Lor wrote: >> Anyone know why -G flag is not supported in the Dtrace port in >> Leopard? This makes the dtrace cmd in Leopard incompatible with >> that on Solaris, and it''s already causing problem with PostgreSQL. >> >> -Robert > >> Date: Fri, 26 Oct 2007 07:30:10 +0000 (GMT) >> From: Lee Packham <lpackham at gmail.com> >> Subject: [BUGS] BUG #3699: Fails to compile DTrace Support >> To: pgsql-bugs at postgresql.org >> X-Mailing-List: pgsql-bugs >> >> >> The following bug has been logged online: >> >> Bug reference: 3699 >> Logged by: Lee Packham >> Email address: lpackham at gmail.com >> PostgreSQL version: 8.2.5 >> Operating system: OSX Leopard >> Description: Fails to compile DTrace Support >> Details: >> >> I have built a patch to enable a working DTrace on OSX with >> Postgres 8.2.5. >> Basically the problem is that the dtrace command on OSX doesn''t >> have the -G >> parameter - so you have to use the newer -h method to produce a >> header file. >> >> >> I have put the patch on my blog. >> >> http://leenux.org.uk/dtrace-patches/dtrace-with-postgres-on-osx >> >> Hope this is of use to you guys. >> >> Cheers, >> >> Lee Packham >> >> ---------------------------(end of >> broadcast)--------------------------- >> TIP 4: Have you searched our list archives? >> >> http://archives.postgresql.org > >> _______________________________________________ >> dtrace-discuss mailing list >> dtrace-discuss at opensolaris.org > > > -- > Adam Leventhal, FishWorks http://blogs.sun.com/ahl > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.orgSteve Peters scp at mac.com
On Fri, Oct 26, 2007 at 10:08:58AM -0700, Steve Peters wrote:> The Mac OS X "dtrace -h" emits all the information required for > successfully linking a USDT probe by the rest of the toolchain. On Mac > OS X "dtrace -G" is superfluous. For historical reasons "-G" was > disabled early on in the bring up. We''ll take a bug to re-introduce "- > G" as a no-op with a warning message. > > See the section "BUILDING CODE CONTAINING USDT PROBES" in the Leopard > dtrace(1) man page. > > Static probes work very nicely on Mac OS X (thank you!) A number of > our frameworks ship with "Is Enabled" static probes in Leopard.Steve, That''s terrific (and my apologies for doubting your DTrace implementation even for a second)! Was this done by making modifications to your linker or gcc perhaps? And congratulations to you and your colleagues on the port of DTrace to Mac OS X. We hope to hear from you all much more now that it''s in the wild. Adam -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
Adam Leventhal wrote:> On Fri, Oct 26, 2007 at 10:08:58AM -0700, Steve Peters wrote: >> The Mac OS X "dtrace -h" emits all the information required for >> successfully linking a USDT probe by the rest of the toolchain. On Mac >> OS X "dtrace -G" is superfluous. For historical reasons "-G" was >> disabled early on in the bring up. We''ll take a bug to re-introduce "- >> G" as a no-op with a warning message. >> >> See the section "BUILDING CODE CONTAINING USDT PROBES" in the Leopard >> dtrace(1) man page. >> >> Static probes work very nicely on Mac OS X (thank you!) A number of >> our frameworks ship with "Is Enabled" static probes in Leopard. > > Steve, > > That''s terrific (and my apologies for doubting your DTrace implementation > even for a second)! Was this done by making modifications to your linker > or gcc perhaps? > > And congratulations to you and your colleagues on the port of DTrace to > Mac OS X. We hope to hear from you all much more now that it''s in the > wild. > > Adam >I would like to say congratulations and thank you as well. I just did my first DTracing on my iMac today. Once I get my MacBook Pro updated, then life will be complete - I will have DTrace capability on everything I use ;) Thanks, Jarod
Hi Steve, From: Steve Peters <scp at mac.com>> > The Mac OS X "dtrace -h" emits all the information required for > successfully linking a USDT probe by the rest of the toolchain. On Mac > > OS X "dtrace -G" is superfluous. For historical reasons "-G" was > disabled early on in the bring up. We''ll take a bug to re-introduce "- > > G" as a no-op with a warning message. > > See the section "BUILDING CODE CONTAINING USDT PROBES" in the Leopard > > dtrace(1) man page. >In Postgres we follow the old way of implementing USDT. 1) add probes to src.c 2) cc -c src.c -o src.o 3) dtrace -G -s probes.d src.o ... 4) cc -o postgres src.o probes.o This works fine on Solaris but it breaks on OSX since the -G flag doesn''t exist (adding it with no-op won''t help). Can this still be done in OSX (replacing -G with -h?) or does it only support the new way where the .h file has to be produced first? If not, I''d say the two implementations have incompatible behavior. -Robert
On Fri, Oct 26, 2007 at 03:38:03PM -0500, Robert Lor wrote:> In Postgres we follow the old way of implementing USDT. > > 1) add probes to src.c > 2) cc -c src.c -o src.o > 3) dtrace -G -s probes.d src.o ... > 4) cc -o postgres src.o probes.o > > This works fine on Solaris but it breaks on OSX since the -G flag > doesn''t exist (adding it with no-op won''t help). Can this still be > done in OSX (replacing -G with -h?) or does it only support the new way > where the .h file has to be produced first? If not, I''d say the two > implementations have incompatible behavior.It should be sufficient to just remove the ''dtrace -G ...'' step. Adam -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
From: Adam Leventhal <ahl at eng.sun.com>> On Fri, Oct 26, 2007 at 03:38:03PM -0500, Robert Lor wrote: > > In Postgres we follow the old way of implementing USDT. > > > > 1) add probes to src.c > > 2) cc -c src.c -o src.o > > 3) dtrace -G -s probes.d src.o ... > > 4) cc -o postgres src.o probes.o > > > > This works fine on Solaris but it breaks on OSX since the -G flag > > doesn''t exist (adding it with no-op won''t help). Can this still be > > done in OSX (replacing -G with -h?) or does it only support the new > way > > where the .h file has to be produced first? If not, I''d say the two > > implementations have incompatible behavior. > > It should be sufficient to just remove the ''dtrace -G ...'' step.We''re not using ''dtrace -h'' now, so I''m not following how the ''dtrace -G..." step can be removed. Maybe I''m missing something! -Robert
On Fri, Oct 26, 2007 at 04:51:44PM -0500, Robert Lor wrote:> We''re not using ''dtrace -h'' now, so I''m not following how the ''dtrace -G..." > step can be removed. Maybe I''m missing something!Ah. I thought that Apple might have added <sys/dtrace.h> and kept the output of ''dtrace -h'' compatible with the macros. In fact, they''ve done something sort of clever. The generated header file contains a slightly different reference to the private symbol names; Apple them must have modified their compiler or linker to do the work of ''dtrace -G''. I say sort of clever because the probes themselves contain the stability information whereas we use ''dtrace -G'' to transmit the stability into the final DOF object. I''ve included an example here for the probe foo*:::bar. Note that is-enabled probes don''t have the stability magic so I''m not sure how things would work if only is-enabled probes were used. ---8<--- /* * Generated by dtrace(1M). */ #ifndef _PROV_H #define _PROV_H #include <unistd.h> #ifdef __cplusplus extern "C" { #endif #define FOO_STABILITY "___dtrace_stability$foo$v1$1_1_0_1_1_0_1_1_0_1_1_0_1_1_0" #define FOO_TYPEDEFS "___dtrace_typedefs$foo$v1" #define FOO_BAR() \ { \ __asm__ volatile(".reference " FOO_TYPEDEFS); \ __dtrace_probe$foo$bar$v1(); \ __asm__ volatile(".reference " FOO_STABILITY); \ } #define FOO_BAR_ENABLED() \ __dtrace_isenabled$foo$bar$v1() extern void __dtrace_probe$foo$bar$v1(void); extern int __dtrace_isenabled$foo$bar$v1(void); #ifdef __cplusplus } #endif #endif /* _PROV_H */ --->8--- To all USDT developers: you should definitely start using ''dtrace -h'' To Apple: you should make dtrace -G a no-op so that said developers don''t have to change their Makefiles Adam -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
> To all USDT developers: you should definitely start using ''dtrace -h'' > To Apple: you should make dtrace -G a no-op so that said developers don''t > have to change their Makefiles... and if you want to be really kind, dtrace -G could generate a dummy object file (again, so developers don''t have to change their Makefiles). Adam -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
On Oct 26, 2007, at 3:27 PM, Adam Leventhal wrote:> On Fri, Oct 26, 2007 at 04:51:44PM -0500, Robert Lor wrote: >> We''re not using ''dtrace -h'' now, so I''m not following how the >> ''dtrace -G..." >> step can be removed. Maybe I''m missing something! > > Ah. I thought that Apple might have added <sys/dtrace.h> and kept > the output > of ''dtrace -h'' compatible with the macros. In fact, they''ve done > something > sort of clever. The generated header file contains a slightly > different > reference to the private symbol names; Apple them must have modified > their > compiler or linker to do the work of ''dtrace -G''. > > I say sort of clever because the probes themselves contain the > stability > information whereas we use ''dtrace -G'' to transmit the stability > into the > final DOF object. I''ve included an example here for the probe > foo*:::bar. > Note that is-enabled probes don''t have the stability magic so I''m > not sure > how things would work if only is-enabled probes were used. > > To all USDT developers: you should definitely start using ''dtrace -h'' > To Apple: you should make dtrace -G a no-op so that said developers > don''t > have to change their Makefiles > > AdamIt looks like you''ve worked out most of the details already, but just for clarification :-). OS X doesn''t support the older DTRACE_PROBE style macros, only the newer (and much safer!) typechecked generated header files. We did actually look at trying to support a compatibility mode with -G being a no-op, but that turned out to be something of a slippery slope. The harder I pulled on that thread, the more corner cases I found where it fell over. As Steve mentioned, we know its an issue, and I filed: <rdar://problem/5566030> Emulate dtrace -G for compatibility Your insight about the is-enabled probes is on target, if you attempt to only use is-enabled probes, and never reference the actual dtrace probe, you''ll get link time errors. James M
On Mon, Oct 29, 2007 at 01:43:19PM -0700, James McIlree wrote:> OS X doesn''t support the older DTRACE_PROBE style macros, only > the newer (and much safer!) typechecked generated header files.That makes sense to me, but some folks -- such as the Postgres folks -- were fond of the DTRACE_PROBE syntax. It might be worth figuring out why...> We did actually look at trying to support a compatibility mode with > -G > being a no-op, but that turned out to be something of a slippery slope. > The harder I pulled on that thread, the more corner cases I found where > it fell over. As Steve mentioned, we know its an issue, and I filed: > > <rdar://problem/5566030> Emulate dtrace -G for compatibilityExcellent. I wrote a wrapper script that emulates -G by just emitting an effectively empty object file. Is there some edge case in which that technique would be insufficient?> Your insight about the is-enabled probes is on target, if you attempt > to only use is-enabled probes, and never reference the actual dtrace > probe, you''ll get link time errors.I''m surprised the DTrace test suite didn''t pick that up. Specifically, this guy should have failed: usr/src/cmd/dtrace/test/tst/common/usdt/tst.onlyenabled.ksh Do you have a bug filed on this or should I file one? Adam -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
On Oct 29, 2007, at 4:48 PM, Adam Leventhal wrote:> On Mon, Oct 29, 2007 at 01:43:19PM -0700, James McIlree wrote: >> OS X doesn''t support the older DTRACE_PROBE style macros, only >> the newer (and much safer!) typechecked generated header files. > > That makes sense to me, but some folks -- such as the Postgres folks > -- > were fond of the DTRACE_PROBE syntax. It might be worth figuring out > why... > >> We did actually look at trying to support a compatibility mode with >> -G >> being a no-op, but that turned out to be something of a slippery >> slope. >> The harder I pulled on that thread, the more corner cases I found >> where >> it fell over. As Steve mentioned, we know its an issue, and I filed: >> >> <rdar://problem/5566030> Emulate dtrace -G for compatibility > > Excellent. I wrote a wrapper script that emulates -G by just > emitting an > effectively empty object file. Is there some edge case in which that > technique would be insufficient?The OS X linker will helpfully report an error if you pass it an empty object file. There are various things you can add to the object file to suppress the "nothing''s here" warning. Depending on what flags you pass, you should get away with "mostly empty" most of the time.> > >> Your insight about the is-enabled probes is on target, if you >> attempt >> to only use is-enabled probes, and never reference the actual dtrace >> probe, you''ll get link time errors. > > I''m surprised the DTrace test suite didn''t pick that up. > Specifically, this > guy should have failed: > > usr/src/cmd/dtrace/test/tst/common/usdt/tst.onlyenabled.ksh > > Do you have a bug filed on this or should I file one?No radar on this yet. Do you know of any use cases for this kind of construct? James M
On Mon, Oct 29, 2007 at 05:44:50PM -0700, James McIlree wrote:> >Excellent. I wrote a wrapper script that emulates -G by just > >emitting an > >effectively empty object file. Is there some edge case in which that > >technique would be insufficient? > > The OS X linker will helpfully report an error if you pass it an > empty > object file. There are various things you can add to the object file > to suppress > the "nothing''s here" warning. Depending on what flags you pass, you > should get away with "mostly empty" most of the time.That''s annoying.> >> Your insight about the is-enabled probes is on target, if you > >>attempt > >>to only use is-enabled probes, and never reference the actual dtrace > >>probe, you''ll get link time errors. > > > >I''m surprised the DTrace test suite didn''t pick that up. > >Specifically, this > >guy should have failed: > > > > usr/src/cmd/dtrace/test/tst/common/usdt/tst.onlyenabled.ksh > > > >Do you have a bug filed on this or should I file one? > > No radar on this yet. Do you know of any use cases for this kind of > construct?The bug reporter thing seems to be down. We''ve used this to create embedded test frameworks were we use DTrace to perform safe dynamic instrumentation to effect error injection for example. I take it you guys haven''t been running the test suite? Adam -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
On Oct 30, 2007, at 6:16 PM, Adam Leventhal wrote:> I take it you guys haven''t been running the test suite?Au contraire ... we run 951 cases, and pass them all (thank you!). But early on we deferred tst/common/usdt/* and didn''t have time to rework them (Solaris-isms, -G, etc). usdt got plenty of testing, though not in all the corner cases. SCP -- Steve Peters scp at mac.com
On Wed, Oct 31, 2007 at 09:17:24AM -0700, Steve Peters wrote:> >I take it you guys haven''t been running the test suite? > > Au contraire ... we run 951 cases, and pass them all (thank you!). But > early on we deferred tst/common/usdt/* and didn''t have time to rework > them (Solaris-isms, -G, etc). usdt got plenty of testing, though not > in all the corner cases.Excellent! I hope that it was helpful. Porting was one of the primary reasons why we wanted to get the test suite putback into ON. Adam -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
James, From: James McIlree <jmcilree at apple.com>> > OS X doesn''t support the older DTRACE_PROBE style macros, only > the newer (and much safer!) typechecked generated header files. >The DTRACE_PROBE macros are still being exposed in sdt.h. I tried using them without running "dtrace -G", and the app built successfully except none of the probes were available. Is there any chance that this approach can be made to work, if not now, in the future? -Robert
On Nov 2, 2007, at 1:36 PM, Robert Lor wrote:> James, > > From: James McIlree <jmcilree at apple.com> >> >> OS X doesn''t support the older DTRACE_PROBE style macros, only >> the newer (and much safer!) typechecked generated header files. >> > > The DTRACE_PROBE macros are still being exposed in sdt.h. I tried > using them without running "dtrace -G", and the app built > successfully except none of the probes were available. Is there any > chance that this approach can be made to work, if not now, in the > future? > > -RobertRobert, The sdt.h DTRACE_PROBE macros are vestigial, they''ll go away any minute now. I can''t think of a way to make them work without the generated -h files off the top of my head, but it is software, and all things are possible :-). That said, the earliest possible date we could fix this is a ways off, and the DTRACE_PROBE macros were obsoleted for good reason. I think it would be possible to do a fairly simple mechanical translation of DTRACE_PROBE style to the new generated header style, and that might get you going quicker. James M
James, From: James McIlree <jmcilree at apple.com>> > The sdt.h DTRACE_PROBE macros are vestigial, they''ll go away any > minute now. > > I can''t think of a way to make them work without the generated -h > files off the top of > my head, but it is software, and all things are possible :-). > > That said, the earliest possible date we could fix this is a ways > off, and the > DTRACE_PROBE macros were obsoleted for good reason. I think it would be > possible to do a fairly simple mechanical translation of DTRACE_PROBE > > style > to the new generated header style, and that might get you going quicker. >Thanks for the clarification. -Robert