[dtrace-discuss] Newbie Question

[Rayson Ho]

Hi Daniel,

Since the definition of __FILE__ is added by the C pre-processor,
which is very early in the stage when the source file gets translated
into an object file, can you just run the C pre-processor on those
files that dtrace does not like to see what the input to the compiler
looks like??

http://developers.sun.com/sunstudio/documentation/ss11/mr/man1/cc.1.html

-E   Runs the source file through the preprocessor only and
          sends the output to stdout. The preprocessor is built
          directly into the compiler, except in -Xs mode, where
          /usr/ccs/lib/cpp is invoked. Includes the preprocessor
          line numbering information. See also -P option.

Rayson



On 7/24/07, Daniel Templeton <Dan.Templeton at sun.com> wrote:
> One more interesting tidbit.  The char * that dtrace doesn't like is
> coming from a __FILE__ macro in the source code:
>
> #define DRETURN(ret)                            \
>   DSGE_EXIT(SGE_FUNC, __FILE__, __LINE__);      \
>   return ret
>
> Most of the time it works, but for some functions it doesn't.  I'm using
> Studio 11 on AMD64.
>
> Daniel
>
> Daniel Templeton wrote:
> > Adam,
> >
> > Thanks for the help.  I found a way to cheat together a functional
> > build, but I have absolutely no idea how I'm going to automate this.
> > The issues are deep and many. :)
> >
> > On to a new problem.  Here's my script:
> >
> > ---
> >
> > #!/usr/sbin/dtrace -s
> >
> > #pragma D option quiet
> >
> > dsge$1:::enter
> > {
> >   printf("--> %s() {\n", copyinstr(arg0));
> > }
> >
> > dsge$1:::exit
> > {
> >   printf("<-- %s() %s %d }\n", copyinstr(arg0), copyinstr(arg1), arg2);
> > }
> >
> > dsge$1:::info
> > {
> >   printf("%s\n", copyinstr(arg0));
> > }
> >
> > ---
> >
> > It works fine, mostly.  In certain places, I get output like the
> > following:
> >
> > dtrace: error on enabled probe ID 1397 (ID 12048:
> > dsge4164:sge_execd:mconf_get_simulate_hosts:exit): invalid address
> > (0x5e1b87) in action #2 at DIF offset 28
> >
> > Clearly, dtrace couldn't resolve one of the char *'s.  It happens
> > every time this probe gets called.  It also happens more randomly with
> > some other probes.  Is dtrace finding pointer problems in the source
> > code, or is this problem related to memory getting paged around?  In
> > other words, should I be debugging my project or the DTrace end of
> > things?
> >
> > Thanks!
> > Daniel
> >
> > Adam Leventhal wrote:
> >> On Tue, Jul 24, 2007 at 08:31:56AM -0700, Daniel Templeton wrote:
> >>
> >>> Given that the archives are here to stay, let me ask a few questions
> >>> to clarify my best approach:
> >>>
> >>> 0) Does dtrace -G have to be run on all the object files in the binary?
> >>>
> >>
> >> It has to be run on every object file that has USDT probes or is-enabled
> >> tracepoints; in this case, that means every file that calls dprintf().
> >>
> >>
> >>> 1) Does dtrace -G have to be run on all the object files at once?
> >>>
> >>
> >> That's an interesting thought. Right now, you can't do that because
> >> DTrace
> >> only allows one DOF container for a given ELF load object. This was
> >> done to
> >> prevent duplicate registration, but allowing multiple containers per
> >> object
> >> is arguably a useful feature and there are other ways to prevent
> >> duplicate
> >> registration.
> >>
> >>
> >>> 2) Can I run it on the object files in groups, such as right before
> >>> the archives get created, and then include the resulting object file
> >>> in the archive?
> >>>
> >>
> >> That pretty much amounts to the same thing as (1) unfortunately.
> >>
> >>
> >>> 3) What happens if dtrace -G gets run on the same object file twice?
> >>>
> >>
> >> Running dtrace -G has the result of identifying calls to tracepoints,
> >> recording their locations, and modifying them to be nops. A
> >> subsequent run
> >> will identify and record the locations, but make no modifications.
> >> This is
> >> necessary to support a incremental build environments.
> >>
> >> I'd suggest you just unpack the archives (ar -x) and use the raw
> >> object files.
> >>
> >> Adam
> >>
> >>
> >
> >
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
>