Howdy,
I am trying to migrate several scripts to use application defined types,
and am running into a few issues. When I attempt to run a script with a
application defined type, it looks like the DTrace preprocessor is getting
angry with me:
$ cat view.d
#include "httpd.h"
:::acceptconnection
{
this->addr = (conn_rec *)copyin(arg0,sizeof(conn_rec *));
}
$ dtrace -C -I/tmp/apache/include -s view.d
dtrace: failed to compile script view.d:
"/tmp/apache/include/apr_thread_mutex.h", line 100: syntax error near
"#"
At first I thought there was an issue with the header files, so I
ran CPP by hand to generate a header file to include:
$ cat test.c
#include "httpd.h"
$ cpp -I/tmp/apache/include test.c > http.h
$ cat view.d
#include "http.h"
:::acceptconnection
{
this->addr = (conn_rec *)copyin(arg0,sizeof(conn_rec *));
}
$ dtrace -C -I`pwd` -s view.d
dtrace: failed to compile script view.d: "/usr/include/sys/va_list.h",
line 99: syntax error near "__gnuc_va_list"
I read through the DTrace users guide and reviewed Mike''s post in the
discussion forums:
http://www.opensolaris.org/jive/thread.jspa?threadID=3289&tstart=15
And from what I can tell I am defining things correctly. Does anyone see
any issues with what I am doing? Does anyone happen to know what is
causing the preprocessor to yell at me? Is this one of those issues where
gcc and cc are not playing well together?
Thanks for any insight,
- Ryan
--
UNIX Administrator
http://daemons.net/~matty
> > Howdy, > > I am trying to migrate several scripts to use application defined types, > and am running into a few issues. When I attempt to run a script with a > application defined type, it looks like the DTrace preprocessor is getting > angry with me: > > $ cat view.d > #include "httpd.h" > > :::acceptconnection > { > this->addr = (conn_rec *)copyin(arg0,sizeof(conn_rec *)); > } > > $ dtrace -C -I/tmp/apache/include -s view.d > dtrace: failed to compile script view.d: > "/tmp/apache/include/apr_thread_mutex.h", line 100: syntax error near "#" > > At first I thought there was an issue with the header files, so I > ran CPP by hand to generate a header file to include: > > $ cat test.c > #include "httpd.h" > > $ cpp -I/tmp/apache/include test.c > http.h > > $ cat view.d > #include "http.h" > > :::acceptconnection > { > this->addr = (conn_rec *)copyin(arg0,sizeof(conn_rec *)); > } > > $ dtrace -C -I`pwd` -s view.d > dtrace: failed to compile script view.d: "/usr/include/sys/va_list.h", > line 99: syntax error near "__gnuc_va_list"Unfortunately our cpp is a very old one, and that was the only one that was bundled when DTrace integrated. Try switching your DTrace cpp to the gcc one to use with these gcc sources: $ dtrace -C -xcpppath=/usr/sfw/bin/cpp or wherever you keep your gcc cpp. If that also fails, e-mail me the error message from that and I''ll help you get it working (there are some things I still haven''t done to make D play nice with GCC''s cpp) -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
Howdy, I am getting errors when trying to include arbitrary header files: $ dtrace -C -I/usr/apache2/include -s foo.d dtrace: failed to compile script foo.d: "/usr/apache2/include/apr_thread_mutex.h", line 99: syntax error near "#" And wondered if anyone has had an opportunity to look at this issue? I would like to be able to use types in my DTrace scripts, but the preprocessor issues are preventing me from doing so. :( Thanks for any insight, - Ryan -- UNIX Administrator http://daemons.net/~matty
Hey Ryan, apr_thread_mutex.h is using the APR_POOL_DECLARE_ACCESSOR() macro defined in apr_pools.h. THat macro uses the ## preprocessor concatenation operator, and the very of cpp that dtrace(1M) uses by default (/usr/ccs/lib/cpp) is rather old and crotchety and doesn''t understand the operator. You can work around this, by using another version of cpp, /usr/sfw/bin/cpp for example: dtrace -xcpppath=/usr/sfw/bin/cpp -C -I/usr/apache2/include -e -s foo.d Doing this allowed me to include apr_thread_mutex.h without a problem. This begs the question, of course: why don''t we just use that cpp by default if the one in /usr/ccs/lib is so busted. We made this decision because /usr/sfw is in a different consolidation (Solaris is made of several consolidations of which the kernel is just one; Java and X are two others for example) and creating a cross-consolidation dependency can be a bit tricky. We have, however, been discussing this issue as more folks bump into the limitations of /usr/ccs/lib/cpp, and we may change this in the not-too-distant future. Adam On Sat, Dec 10, 2005 at 10:36:19PM -0500, Matty wrote:> > Howdy, > > I am getting errors when trying to include arbitrary header files: > > $ dtrace -C -I/usr/apache2/include -s foo.d > dtrace: failed to compile script foo.d: > "/usr/apache2/include/apr_thread_mutex.h", line 99: syntax error near "#" > > And wondered if anyone has had an opportunity to look at this issue? I > would like to be able to use types in my DTrace scripts, but the > preprocessor issues are preventing me from doing so. :( > > Thanks for any insight, > - Ryan > -- > UNIX Administrator > http://daemons.net/~matty > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
> This begs the question, of course: why don''t we just > use that cpp by default > if the one in /usr/ccs/lib is so busted. We made this > decision because > /usr/sfw is in a different consolidation (Solaris is > made of several > consolidations of which the kernel is just one; Java > and X are two others > for example) and creating a cross-consolidation > dependency can be a bit > tricky. We have, however, been discussing this issue > as more folks bump > into the limitations of /usr/ccs/lib/cpp, and we may > change this in the > not-too-distant future.Question is PSARC involved with cross consolidation issues like this and the primary objective is to resolve problems like this before they happen? ---Bob This message posted from opensolaris.org
Yes they are. On Wed, Dec 14, 2005 at 01:52:24AM -0800, Bob Palowoda wrote:> > This begs the question, of course: why don''t we just > > use that cpp by default > > if the one in /usr/ccs/lib is so busted. We made this > > decision because > > /usr/sfw is in a different consolidation (Solaris is > > made of several > > consolidations of which the kernel is just one; Java > > and X are two others > > for example) and creating a cross-consolidation > > dependency can be a bit > > tricky. We have, however, been discussing this issue > > as more folks bump > > into the limitations of /usr/ccs/lib/cpp, and we may > > change this in the > > not-too-distant future. > > Question is PSARC involved with cross consolidation > issues like this and the primary objective is to resolve > problems like this before they happen? > > ---Bob > This message posted from opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
Hi Mike,
I''ve just encountered the exact same problem and unfortunately using
gcc didn''t solve my problem. :-( I''m wondering if you had
managed to solve this for Ryan?
This is the D Script I''m trying to use:
# cat foo.d
#include "db.h"
BEGIN
{
}
and the output I get:
# dtrace -xcpppath=/usr/sfw/bin/cpp -Xs -C -I /db32/include -s foo2.d
dtrace: failed to compile script foo2.d: "/usr/include/sys/va_list.h",
line 99: syntax error near "__gnuc_va_list"
Got any ideas how I might be able to resolve this?
Thanks,
Chris
--
This message posted from opensolaris.org