I''m using cpp rather heavily in creating my DTrace script,
so I may well be fouling myself up. Anyway, I''m getting:
% sudo dtrace -I. -C -s dtlog.d 1
dtrace: failed to compile script dtlog.d: line 89:
syntax error near "1"
When I look at the cpp output for line 89, I get:
syscall::chmod:entry {
self->arg1 = arg1;
self->arg0 = arg0;
self->follow = 1;
} /* 4 */
Actually, this is all on one line. I don''t see anything
wrong with the syntax. Help?
-r
--
http://www.cfcl.com/rdm Rich Morin
http://www.cfcl.com/rdm/resume rdm at cfcl.com
http://www.cfcl.com/rdm/weblog +1 650-873-7841
Technical editing and writing, programming, and web development
> I''m using cpp rather heavily in creating my DTrace script, > so I may well be fouling myself up. Anyway, I''m getting: > > % sudo dtrace -I. -C -s dtlog.d 1 > dtrace: failed to compile script dtlog.d: line 89: > syntax error near "1" > > When I look at the cpp output for line 89, I get: > > syscall::chmod:entry { > self->arg1 = arg1; > self->arg0 = arg0; > self->follow = 1; > } /* 4 */ > > Actually, this is all on one line. I don''t see anything > wrong with the syntax. Help? > > -rThat output compiles for me. Can you post the original dtlog.d input file? -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
At 22:35 -0800 11/18/07, Michael Shapiro wrote:> That output compiles for me. > Can you post the original dtlog.d input file?Sure. Even better, I can post a massively cut-down version that exhibits the same problem: % cat d4.d #include "m4.d" E(chmod) P1a { S1 } % cat m4.d define E(x) syscall::x:entry #define S(x) self->arg/**/x = arg/**/x #define Sf self->follow = 1; #define S0 S(0); Sf #define S1 S(1); S0 #define P1a % sudo dtrace -I. -C -s d4.d dtrace: failed to compile script d4.d: line 3: syntax error near "1" % cpp -C d4.d # 1 "d4.d" # 1 "<built-in>" # 1 "<command line>" # 1 "d4.d" # 1 "m4.d" 1 # 2 "d4.d" 2 syscall::chmod:entry { self->arg1 = arg1; self->arg0 = arg0; self->follow = 1; } % Don''t try to make any sense out of the code, out of context. The only thing I''m trying to resolve right now is the syntax error. If and when I get everything running, I''ll post the entire script with comments and all... -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm at cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development
On Mon, Nov 19, 2007 at 07:00:52PM -0800, Rich Morin wrote:> At 22:35 -0800 11/18/07, Michael Shapiro wrote: > > That output compiles for me. > > Can you post the original dtlog.d input file? > > Sure. Even better, I can post a massively cut-down version > that exhibits the same problem: > > > % cat d4.d > #include "m4.d" > > E(chmod) P1a { S1 } > % cat m4.d > define E(x) syscall::x:entry > #define S(x) self->arg/**/x = arg/**/x > #define Sf self->follow = 1; > #define S0 S(0); Sf > #define S1 S(1); S0 > #define P1a > % sudo dtrace -I. -C -s d4.d > dtrace: failed to compile script d4.d: line 3: syntax error near "1" > % cpp -C d4.d > # 1 "d4.d" > # 1 "<built-in>" > # 1 "<command line>" > # 1 "d4.d" > > # 1 "m4.d" 1 > # 2 "d4.d" 2 > > syscall::chmod:entry { self->arg1 = arg1; self->arg0 = arg0; self->follow > = 1; } > % > > Don''t try to make any sense out of the code, out of context. The > only thing I''m trying to resolve right now is the syntax error. If > and when I get everything running, I''ll post the entire script with > comments and all... > > -rHmm. That exact sequence, minus sudo, works for me on latest bits. Can you (a) reproduce without sudo? I can''t see how that can affect it but let''s be sure. Also (b) what build do you have? (uname -a output) -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
Rich Morin wrote:> At 22:35 -0800 11/18/07, Michael Shapiro wrote: >> That output compiles for me. >> Can you post the original dtlog.d input file? > > Sure. Even better, I can post a massively cut-down version > that exhibits the same problem: > > > % cat d4.d > #include "m4.d" > > E(chmod) P1a { S1 } > % cat m4.d > define E(x) syscall::x:entry > #define S(x) self->arg/**/x = arg/**/x > #define Sf self->follow = 1; > #define S0 S(0); Sf > #define S1 S(1); S0 > #define P1a > % sudo dtrace -I. -C -s d4.d > dtrace: failed to compile script d4.d: line 3: syntax error near "1" > % cpp -C d4.d > # 1 "d4.d" > # 1 "<built-in>" > # 1 "<command line>" > # 1 "d4.d" > > # 1 "m4.d" 1 > # 2 "d4.d" 2 > > syscall::chmod:entry { self->arg1 = arg1; self->arg0 = arg0; self->follow > = 1; } > % > > > Don''t try to make any sense out of the code, out of context. The > only thing I''m trying to resolve right now is the syntax error. If > and when I get everything running, I''ll post the entire script with > comments and all... > > -rit works for me. Try sudo truss -f -t exec -a dtrace -I. -C -s d4.d and see what cpp you''re getting. I believe you should be getting /usr/ccs/lib/cpp; that''s what I get when it works.
At 19:18 -0800 11/19/07, Dan Mick wrote:> Try sudo truss -f -t exec -a dtrace -I. -C -s d4.d and see > what cpp you''re getting. I believe you should be getting > /usr/ccs/lib/cpp; that''s what I get when it works.% sudo truss -f -t exec -a dtrace -I. -C -s d4.d sudo: truss: command not found Sigh. I could probably find a copy of truss on some Mac OS X archive, but there''s no guarantee that I could get it to work. However, I''m open to suggestions... -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm at cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development
On Mon, Nov 19, 2007 at 07:27:12PM -0800, Rich Morin wrote:> At 19:16 -0800 11/19/07, Mike Shapiro wrote: > > Hmm. That exact sequence, minus sudo, works for me on latest bits. > > Can you (a) reproduce without sudo? I can''t see how that can affect > > it but let''s be sure. > > % dtrace -I. -C -s d3.d > dtrace: failed to initialize dtrace: > DTrace requires additional privileges > % sudo su > Password: > sh-3.2# dtrace -I. -C -s d3.d > dtrace: failed to compile script d3.d: line 5: > syntax error near "1" > > > > Also (b) what build do you have? (uname -a output) > > % uname -a > Darwin spot.local 9.1.0 Darwin Kernel Version 9.1.0: > Wed Oct 31 17:46:22 PDT 2007; > root:xnu-1228.0.2~1/RELEASE_I386 i386Ah. Apologies for not asking about the platform up front. Now that we run everywhere I need to ask that :) This is likely a porting bug in the MacOS X DTrace. Sun''s cpp uses a different control line syntax from GNU cpp and I haven''t yet modified the common DTrace code to understand both of them. Apple guys: can you comment on whether you modified dt_pragma.c to understand GCC cpp, which I assume is your default cpp? Or please post the code to your latest stuff somewhere. You will need to modify that. If you haven''t done so I can give you a quick sketch of what will need to be done there. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
Rich Morin wrote:> At 19:18 -0800 11/19/07, Dan Mick wrote: >> Try sudo truss -f -t exec -a dtrace -I. -C -s d4.d and see >> what cpp you''re getting. I believe you should be getting >> /usr/ccs/lib/cpp; that''s what I get when it works. > > % sudo truss -f -t exec -a dtrace -I. -C -s d4.d > sudo: truss: command not found > > > Sigh. I could probably find a copy of truss on some Mac OS X > archive, but there''s no guarantee that I could get it to work. > However, I''m open to suggestions... > > -rcrap. I didn''t realize this was MacOS; sorry. I bet your C preprocessor is substituting whitespace for /**/ rather than "null".
At 20:00 -0800 11/19/07, Mike Shapiro wrote:> Ah. Apologies for not asking about the platform up front. > Now that we run everywhere I need to ask that :)Not quite everywhere yet, but it''s clearly on a roll...> This is likely a porting bug in the MacOS X DTrace. Sun''s cpp > uses a different control line syntax from GNU cpp and I haven''t > yet modified the common DTrace code to understand both of them.Ah.> Apple guys: can you comment on whether you modified dt_pragma.c > to understand GCC cpp, which I assume is your default cpp? > Or please post the code to your latest stuff somewhere.Apple has an online source code repository for Darwin, etc, but I don''t know how current it is kept with their binary releases.> You will need to modify that. If you haven''t done so I can > give you a quick sketch of what will need to be done there.Erm, was this addressed to the "Apple guys" or to me? In any case, perhaps you could help me to work around the problem while waiting for Apple to get on board with a fix. I gather that the problem is not that cpp can''t process the code, nor that the results wouldn''t work if it did, but that cpp isn''t being given command-line options it understands. However, I''m a bit rusty on cpp, so I''m concerned that the "cpp -C" output I''m creating might not play nicely with dtrace (like, what about the lines that start with "#"?). So, can you give me a set of commands that will (say) cause cpp to process my files into vanilla D code, then tell dtrace to use that code? BTW, many thanks for all the help, guys! -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm at cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development
> So, can you give me a set of commands that will (say) cause cpp to > process my files into vanilla D code, then tell dtrace to use that > code? BTW, many thanks for all the help, guys!cpp d4.d worked for me, given the right cpp. cc -E may well work too. However, here''s an example of why cpp matters: dmick at dmick1> which cpp /usr/sfw/bin/cpp dmick at dmick1> cpp d4.d # 1 "d4.d" # 1 "<built-in>" # 1 "<command line>" # 1 "d4.d" # 1 "m4.d" 1 # 2 "d4.d" 2 syscall::chmod:entry { self->arg 1 = arg 1; self->arg 0 = arg 0; self->follow = 1; } Note the evil spaces in "arg 1" and "arg 0". Now, if we edit those /**/ to ##, and use ''cc -E'' which does ANSI preprocessing, we get dmick at dmick1> cc -E d4.d # 1 "d4.d" # 1 "m4.d" # 7 # 2 "d4.d" syscall : : chmod : entry { self -> arg1 = arg1 ; self -> arg0 = arg0 ; self -> follow = 1 ; } #ident "acomp: Sun C 5.8 Patch 121016-05 2007/01/10" which probably works better. Maybe there''s a switch to whatever cpp you''re using that will make it do ANSI cpp, and you can use ## too? or a switch to make /**/ compress away rather than substitute whitespace?
When I run "cpp -C", the evil spaces do not appear. However,
there''s no telling what options dtrace is sending to cpp. I
looked at the dtrace man page on Leopard, and it says:
-C Run the C preprocessor cpp over D programs before compiling
them. Options can be passed to the C preprocessor using the -D,
-U, -I, and -H options. The degree of C standard conformance
can be selected using the -X option. Refer to the description
of the -X option for a description of the set of tokens defined
by the D compiler when invoking the C preprocessor.
Sadly, there _is_ no description of a -X option in either the cpp or
dtrace man page. Sigh.
-r
--
http://www.cfcl.com/rdm Rich Morin
http://www.cfcl.com/rdm/resume rdm at cfcl.com
http://www.cfcl.com/rdm/weblog +1 650-873-7841
Technical editing and writing, programming, and web development
On Mon, Nov 19, 2007 at 08:25:39PM -0800, Rich Morin wrote:> At 20:00 -0800 11/19/07, Mike Shapiro wrote: > > Ah. Apologies for not asking about the platform up front. > > Now that we run everywhere I need to ask that :) > > Not quite everywhere yet, but it''s clearly on a roll... > > > > This is likely a porting bug in the MacOS X DTrace. Sun''s cpp > > uses a different control line syntax from GNU cpp and I haven''t > > yet modified the common DTrace code to understand both of them. > > Ah. > > > Apple guys: can you comment on whether you modified dt_pragma.c > > to understand GCC cpp, which I assume is your default cpp? > > Or please post the code to your latest stuff somewhere. > > Apple has an online source code repository for Darwin, etc, but I > don''t know how current it is kept with their binary releases. > > > You will need to modify that. If you haven''t done so I can > > give you a quick sketch of what will need to be done there. > > Erm, was this addressed to the "Apple guys" or to me? In any case, > perhaps you could help me to work around the problem while waiting > for Apple to get on board with a fix. > > I gather that the problem is not that cpp can''t process the code, > nor that the results wouldn''t work if it did, but that cpp isn''t > being given command-line options it understands. However, I''m a > bit rusty on cpp, so I''m concerned that the "cpp -C" output I''m > creating might not play nicely with dtrace (like, what about the > lines that start with "#"?). > > So, can you give me a set of commands that will (say) cause cpp to > process my files into vanilla D code, then tell dtrace to use that > code? BTW, many thanks for all the help, guys! > > -rI was referring to the Apple DTrace developers, some of whom are on this alias. They need to help us debug this or point me to their source. In terms of workarounds just run the script through whatever preprocessor you like, get the result, and skip the -C part. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
On Mon, Nov 19, 2007 at 08:48:26PM -0800, Rich Morin wrote:> When I run "cpp -C", the evil spaces do not appear. However, > there''s no telling what options dtrace is sending to cpp. I > looked at the dtrace man page on Leopard, and it says: > > -C Run the C preprocessor cpp over D programs before compiling > them. Options can be passed to the C preprocessor using the -D, > -U, -I, and -H options. The degree of C standard conformance > can be selected using the -X option. Refer to the description > of the -X option for a description of the set of tokens defined > by the D compiler when invoking the C preprocessor. > > Sadly, there _is_ no description of a -X option in either the cpp or > dtrace man page. Sigh. > > -rThere is on Solaris in dtrace(1M): -X a | c | s | t Specify the degree of conformance to the ISO C standard that should be selected when invoking cpp(1) (enabled using the -C option). The -X option argument affects the value and presence of the __STDC__ macro depending upon the value of the argument letter. The -X option supports the following arguments: ... but maybe Apple removed this part. The -X option would also require modifications for gcc cpp. We''ll need someone from Apple to help us figure out what they did here. In the meantime avoid using -C and expand your script first. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
At 20:59 -0800 11/19/07, Mike Shapiro wrote:> In the meantime avoid using -C and expand your script first.Will dtrace be OK with all of the lines like: # 158 "macros.d" or do I need to strip them out? -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm at cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development
> > Apple guys: can you comment on whether you modified dt_pragma.c > > to understand GCC cpp, which I assume is your default cpp? > > Or please post the code to your latest stuff somewhere. > > Apple has an online source code repository for Darwin, etc, but I > don''t know how current it is kept with their binary releases.There is a page that has Leopard src: http://www.opensource.apple.com/darwinsource/10.5/ But the DTrace link is dead. I''ve mailed the Apple folks directly, but I know they''re here as well, so Apple folks: please provide us the link to the 10.5 DTrace source so we can figure out what exactly the bug is here... - Bryan -------------------------------------------------------------------------- Bryan Cantrill, Sun Microsystems FishWorks. http://blogs.sun.com/bmc
Rich Morin <rdm at cfcl.com> wrote:> At 20:59 -0800 11/19/07, Mike Shapiro wrote: > > In the meantime avoid using -C and expand your script first. > > Will dtrace be OK with all of the lines like: > > # 158 "macros.d"Usind .d as suffix is a bad idea if you ever like to use makefiles. .d is in use for files containing dependency make rules since more than 10 years. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling writes:> Rich Morin <rdm at cfcl.com> wrote: > > > At 20:59 -0800 11/19/07, Mike Shapiro wrote: > > > In the meantime avoid using -C and expand your script first. > > > > Will dtrace be OK with all of the lines like: > > > > # 158 "macros.d" > > Usind .d as suffix is a bad idea if you ever like to use makefiles. > .d is in use for files containing dependency make rules since more > than 10 years.And now it''s used for the "D" language. Try "ls /usr/demo/dtrace/" on any box with Solaris or OpenSolaris bits. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
James Carlson <james.d.carlson at sun.com> wrote:> Joerg Schilling writes: > > Rich Morin <rdm at cfcl.com> wrote: > > > > > At 20:59 -0800 11/19/07, Mike Shapiro wrote: > > > > In the meantime avoid using -C and expand your script first. > > > > > > Will dtrace be OK with all of the lines like: > > > > > > # 158 "macros.d" > > > > Usind .d as suffix is a bad idea if you ever like to use makefiles. > > .d is in use for files containing dependency make rules since more > > than 10 years. > > And now it''s used for the "D" language. Try "ls /usr/demo/dtrace/" on > any box with Solaris or OpenSolaris bits.As long as you do not use this in makefiles, you will probably not get into problems.... J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Casper.Dik at Sun.COM
2007-Nov-20 12:51 UTC
[dtrace-discuss] confusing syntax error - help?
>> Usind .d as suffix is a bad idea if you ever like to use makefiles. >> .d is in use for files containing dependency make rules since more >> than 10 years. > >And now it''s used for the "D" language. Try "ls /usr/demo/dtrace/" on >any box with Solaris or OpenSolaris bits.It also does not appear to be used in Solaris make.rules or svr4.make.rules (i.e., the use of the .d suffix is new for Solaris in that sense; personally I have never seen .d used in the sense Joerg describes. Casper
At 19:00 -0800 19/11/07, Rich Morin wrote:>#define S(x) self->arg/**/x = arg/**/xYikes! I''m astonished that folks still uses this sort of pre-ANSI stuff. You sure you can''t switch your macro to use ##? That seems like the most forward-looking solution. At 22:03 -0800 19/11/07, Bryan Cantrill wrote:>There is a page that has Leopard src: > > http://www.opensource.apple.com/darwinsource/10.5/ > >But the DTrace link is dead. I''ve mailed the Apple folks directly, >but I know they''re here as well, so Apple folks: please provide us >the link to the 10.5 DTrace source so we can figure out what exactly >the bug is here...Alas, the lights are on but nobody is home (-: Most of Apple is taking this week off. We get an extra three days of vacation as a reward for earning a bazillion dollars last year. US-based employees are combining these three extra days with the traditional US Thanksgiving holiday, the end result being that they have the whole week off. I''m still working ''cause I''m not based on the US. I''ll take the days at Christmas thank you very much (-: Sorry that the Mac OS X DTrace sources aren''t up. I presume that the folks that Bryan contacted will fix this when they get back from vacation. Looking at the source that I have access to, it seems that there are quite a few Apple-specific changes in this space. You can see how DTrace invokes the C pre-processor using the DYLD_PRINT_OPTS environment variable: $ sudo env DYLD_PRINT_OPTS=1 dtrace -C -s test.d [...] opt[0] = "gcc" opt[1] = "-E" opt[2] = "-xc" opt[3] = "-U__GNUC__" opt[4] = "-include" opt[5] = "/usr/lib/dtrace/dt_cpp.h" opt[6] = "-D__APPLE__" opt[7] = "-D__SUNW_D=1" opt[8] = "-D__SUNW_D_32" opt[9] = "-D__Darwin_9_0_0" opt[10] = "-D__i386__" opt[11] = "-D__SUNW_D_VERSION=0x01002002" opt[12] = "-o" opt[13] = "/dev/fd/6" opt[14] = "/dev/fd/5" [...] These options cause GCC to run in ANSI mode rather than traditional mode. In normal C code you can tell GCC to use traditional pre-processor semantics by passing in the "-traditional-cpp" option. However, I can''t see any way to get DTrace to pass an arbitrary option through to the preprocessor. As such, I don''t think there''s a solution for this other than to preprocessor the file (using either GCC or /usr/bin/cpp) yourself, applying "-traditional-cpp" when you invoke the tool. Also, while it seems that -X is not supported by our DTrace, -x std=XXX is. Alas, it does not actually have any effect on how we invoke the preprocessor. Looks like Mac OS X DTrace has irreversibly moved into the ... late eighties (-: S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
Casper.Dik at Sun.COM wrote:> >>> Usind .d as suffix is a bad idea if you ever like to use makefiles. >>> .d is in use for files containing dependency make rules since more >>> than 10 years. >>> >> And now it''s used for the "D" language. Try "ls /usr/demo/dtrace/" on >> any box with Solaris or OpenSolaris bits. >> > > > It also does not appear to be used in Solaris make.rules or svr4.make.rules > > (i.e., the use of the .d suffix is new for Solaris in that sense; > personally I have never seen .d used in the sense Joerg describes. > >Actually, we ran into the exact problem Joerg describes in Postgres and had to change the dependency files to not use .d. -Robert
At 12:58 +0000 11/20/07, Quinn wrote:> At 19:00 -0800 19/11/07, Rich Morin wrote: >>#define S(x) self->arg/**/x = arg/**/x > > Yikes! I''m astonished that folks still uses this sort > of pre-ANSI stuff. You sure you can''t switch your macro > to use ##? That seems like the most forward-looking > solution.I''ll definitely give it a try. FWIW, the last serious C coding I did was about 20 years ago. These days, I write most of my code in Ruby. Fortunately, I still have my copy of K&R, 2e. "Based on Draft-Proposed ANSI C", no less! Yep, there it is in the index... -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm at cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development
Casper.Dik at Sun.COM
2007-Nov-20 13:39 UTC
[dtrace-discuss] confusing syntax error - help?
>Casper.Dik at Sun.COM wrote: >> >>>> Usind .d as suffix is a bad idea if you ever like to use makefiles. >>>> .d is in use for files containing dependency make rules since more >>>> than 10 years. >>>> >>> And now it''s used for the "D" language. Try "ls /usr/demo/dtrace/" on >>> any box with Solaris or OpenSolaris bits. >>> >> >> >> It also does not appear to be used in Solaris make.rules or svr4.make.rules >> >> (i.e., the use of the .d suffix is new for Solaris in that sense; >> personally I have never seen .d used in the sense Joerg describes. >> >> >Actually, we ran into the exact problem Joerg describes in Postgres and >had to change the dependency files to not use .d.Ah, but that because you''re also using dtrace? Casper
Dan Mick <dan.mick at sun.com> wrote:> Try sudo truss -f -t exec -a dtrace -I. -C -s d4.d and see what cpp you''re > getting. I believe you should be getting /usr/ccs/lib/cpp; that''s what I get > when it works.This is a K&R cpp that behaves different from cc -E which is a ANSI cpp. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Rich Morin <rdm at cfcl.com> wrote:> When I run "cpp -C", the evil spaces do not appear. However, > there''s no telling what options dtrace is sending to cpp. I > looked at the dtrace man page on Leopard, and it says: > > -C Run the C preprocessor cpp over D programs before compiling > them. Options can be passed to the C preprocessor using the -D, > -U, -I, and -H options. The degree of C standard conformance > can be selected using the -X option. Refer to the description > of the -X option for a description of the set of tokens defined > by the D compiler when invoking the C preprocessor. > > Sadly, there _is_ no description of a -X option in either the cpp or > dtrace man page. Sigh./usr/ccs/lib/cpp is not conforming to an official C standard but it is the standard K&R cpp from 30 years ago. Platforms that do not have a UNIX history in background today do not deliver a K&R cpp anymore. You may get a similar behavior woth gcc''s cpp if you use -traditional-cpp. This still gives a different output.... As cpp is non-free, SchilliX pipes the outpout from gcc-cpp -traditional-cpp though /usr/lib/cpp-post which has been written to convert ANSI cpp output to something that looks similar to K&R cpp. #include <schily/mconfig.h> #include <stdio.h> #include <schily/schily.h> int fixline __PR((char *line, int amt)); main() { char line[8192]; int amt; while ((amt = fgetline(stdin, line, sizeof (line))) >= 0) { amt = fixline(line, amt); filewrite(stdout, line, amt); putchar(''\n''); } return (0); } fixline(line, amt) char *line; int amt; { char *p = line; if (p[0] != ''#'') return (amt); if (p[1] != '' '') return (amt); if (line[amt-1] == ''"'') { line[amt] = '' ''; line[amt+1] = ''\0''; amt += 1; } return (amt); } J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Casper.Dik at Sun.COM wrote:> >> .d is in use for files containing dependency make rules since more > >> than 10 years. > > > >And now it''s used for the "D" language. Try "ls /usr/demo/dtrace/" on > >any box with Solaris or OpenSolaris bits. > > > It also does not appear to be used in Solaris make.rules or svr4.make.rules > > (i.e., the use of the .d suffix is new for Solaris in that sense; > personally I have never seen .d used in the sense Joerg describes.If is common practice since at least 10 year. It seems that you did not look at OSS makefiles recently. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Rich Morin <rdm at cfcl.com> wrote:> At 12:58 +0000 11/20/07, Quinn wrote: > > At 19:00 -0800 19/11/07, Rich Morin wrote: > >>#define S(x) self->arg/**/x = arg/**/x > > > > Yikes! I''m astonished that folks still uses this sort > > of pre-ANSI stuff. You sure you can''t switch your macro > > to use ##? That seems like the most forward-looking > > solution. > > I''ll definitely give it a try. FWIW, the last serious C > coding I did was about 20 years ago. These days, I write > most of my code in Ruby.If you convert to ## and if Dtrace on Solaris still calls /lib/cpp, it will no longer work on Solaris. Check the __CONCAT__ macro in /usr/include/sys/*.h J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling wrote:> Dan Mick <dan.mick at sun.com> wrote: > >> Try sudo truss -f -t exec -a dtrace -I. -C -s d4.d and see what cpp you''re >> getting. I believe you should be getting /usr/ccs/lib/cpp; that''s what I get >> when it works. > > This is a K&R cpp that behaves different from cc -E which is a ANSI cpp.That''s correct, though irrelevant; the relevant point is that it translates /**/ into a null string.
Casper.Dik at sun.com wrote:> >>> Usind .d as suffix is a bad idea if you ever like to use makefiles. >>> .d is in use for files containing dependency make rules since more >>> than 10 years. >> And now it''s used for the "D" language. Try "ls /usr/demo/dtrace/" on >> any box with Solaris or OpenSolaris bits. > > > It also does not appear to be used in Solaris make.rules or svr4.make.rules > > (i.e., the use of the .d suffix is new for Solaris in that sense; > personally I have never seen .d used in the sense Joerg describes.me either; I''ve seen .dep, but not .d. Certainly I''ve never had a conflict naming a file .d, but then, I don''t tend to use D in makefile projects at all.
Dan Mick <dan.mick at sun.com> wrote:> Joerg Schilling wrote: > > Dan Mick <dan.mick at sun.com> wrote: > > > >> Try sudo truss -f -t exec -a dtrace -I. -C -s d4.d and see what cpp you''re > >> getting. I believe you should be getting /usr/ccs/lib/cpp; that''s what I get > >> when it works. > > > > This is a K&R cpp that behaves different from cc -E which is a ANSI cpp. > > That''s correct, though irrelevant; the relevant point is that it translates > /**/ into a null string.Which is a result of the fact that it is a K&R cpp. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
At 15:36 +0100 11/20/07, Joerg Schilling wrote:> If you convert to ## and if Dtrace on Solaris still calls > /lib/cpp, it will no longer work on Solaris. > > Check the __CONCAT__ macro in /usr/include/sys/*.hWell, "grep __CONCAT__ /usr/include/sys/*.h" comes up empty on Leopard, so no help there. However, Googling about, I do see some examples of __CONCAT__ definitions. I wonder if I need to do something like this, for portability: #if __APPLE__ #define __CONCAT__(A,B) A ## B #else #define __CONCAT__(A,B) A/**/B #endif then use __CONCAT__ in the following code. Problem is, I don''t know what the #if test should be. __APPLE__ is a bit too specific... Comments? Clues? Suggestions? -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm at cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development
On Nov 20, 2007, at 7:55 PM, Rich Morin wrote:> At 15:36 +0100 11/20/07, Joerg Schilling wrote: >> If you convert to ## and if Dtrace on Solaris still calls >> /lib/cpp, it will no longer work on Solaris. >> >> Check the __CONCAT__ macro in /usr/include/sys/*.h > > Well, "grep __CONCAT__ /usr/include/sys/*.h" comes up empty > on Leopard, so no help there. However, Googling about, I do > see some examples of __CONCAT__ definitions. > > I wonder if I need to do something like this, for portability: > > #if __APPLE__ > #define __CONCAT__(A,B) A ## B > #else > #define __CONCAT__(A,B) A/**/B > #endif > > then use __CONCAT__ in the following code. Problem is, I > don''t know what the #if test should be. __APPLE__ is a bit > too specific... > > Comments? Clues? Suggestions?Rich, If I''ve read the earlier diagnosis correctly (thanks everyone!), wouldn''t __STDC__ be appropriate? It seems like this is an ANSI vs K&R issue, so I think that should be reasonably close. James M
On Nov 20, 2007, at 7:55 PM, Rich Morin wrote:> At 15:36 +0100 11/20/07, Joerg Schilling wrote: >> If you convert to ## and if Dtrace on Solaris still calls >> /lib/cpp, it will no longer work on Solaris. >> >> Check the __CONCAT__ macro in /usr/include/sys/*.h > > Well, "grep __CONCAT__ /usr/include/sys/*.h" comes up empty > on Leopard, so no help there. However, Googling about, I do > see some examples of __CONCAT__ definitions. > > I wonder if I need to do something like this, for portability: > > #if __APPLE__ > #define __CONCAT__(A,B) A ## B > #else > #define __CONCAT__(A,B) A/**/B > #endif > > then use __CONCAT__ in the following code. Problem is, I > don''t know what the #if test should be. __APPLE__ is a bit > too specific... > > Comments? Clues? Suggestions?One more thing I just noticed. There is a "__CONCAT" in /usr/include/sys/cdefs.h: /* * The __CONCAT macro is used to concatenate parts of symbol names, e.g. * with "#define OLD(foo) __CONCAT(old,foo)", OLD(foo) produces oldfoo. * The __CONCAT macro is a bit tricky -- make sure you don''t put spaces * in between its arguments. __CONCAT can also concatenate double- quoted * strings produced by the __STRING macro, but this only works with ANSI C. */ James M
On Nov 19, 2007, at 8:48 PM, Rich Morin wrote:> When I run "cpp -C", the evil spaces do not appear. However, > there''s no telling what options dtrace is sending to cpp. I > looked at the dtrace man page on Leopard, and it says: > > -C Run the C preprocessor cpp over D programs before compiling > them. Options can be passed to the C preprocessor using the -D, > -U, -I, and -H options. The degree of C standard conformance > can be selected using the -X option. Refer to the description > of the -X option for a description of the set of tokens defined > by the D compiler when invoking the C preprocessor. > > Sadly, there _is_ no description of a -X option in either the cpp or > dtrace man page. Sigh.I take the blame for this, the missing -X is my fault :-(. I don''t remember details, but when I first implemented the various levels of conformance, there were serious problems whenever __STDC__ wasn''t defined. I''m thinking it may have even been a basic gcc header that was causing problems. I disabled it and intended to come back to it later. We all know how well that worked :-). I filed: <rdar://problem/5609671> dtrace needs to support -X (cpp std conformance control) James M
Rich Morin <rdm at cfcl.com> wrote:> At 15:36 +0100 11/20/07, Joerg Schilling wrote: > > If you convert to ## and if Dtrace on Solaris still calls > > /lib/cpp, it will no longer work on Solaris. > > > > Check the __CONCAT__ macro in /usr/include/sys/*.h > > Well, "grep __CONCAT__ /usr/include/sys/*.h" comes up empty > on Leopard, so no help there. However, Googling about, I do > see some examples of __CONCAT__ definitions.OK, this on OpenSolaris> I wonder if I need to do something like this, for portability: > > #if __APPLE__ > #define __CONCAT__(A,B) A ## B > #else > #define __CONCAT__(A,B) A/**/B > #endif > > then use __CONCAT__ in the following code. Problem is, I > don''t know what the #if test should be. __APPLE__ is a bit > too specific...Use e.g.: #ifdef __STDC__ #define __CONCAT__(A,B) A ## B #else #define __CONCAT__(A,B) A/**/B #endif or better: #if __STDC__ - 0 == 0 #define __CONCAT__(A,B) A/**/B #else #define __CONCAT__(A,B) A ## B #endif J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
At 20:28 -0800 11/20/07, James McIlree wrote:> One more thing I just noticed. There is a "__CONCAT" > in /usr/include/sys/cdefs.h:Yep. Can you tell me whether dtrace brings this in? -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm at cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development
Rich Morin <rdm at cfcl.com> wrote:> At 20:28 -0800 11/20/07, James McIlree wrote: > > One more thing I just noticed. There is a "__CONCAT" > > in /usr/include/sys/cdefs.h: > > Yep. Can you tell me whether dtrace brings this in?sys/cdefs.h is a non-standard *BSD only include file. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily