Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Small "getting started" help needed.

On Mon, 2008-06-23 at 16:11 +0200, Schorn, Markus wrote:
> > 2. The AST -- or at least the DOM visualized by the DOM viewer in the
> >    debug tools -- reflects a DOM that has not been preprocessed. I see
> >    why that is useful, but I need to extract an AST for the C code
> >    proper. Can this be done within the given framework? Ideally, is
> >    there a visualizer I can look at as a starting point for how to
> >    get it?
> 
> The AST is built with properly preprocessing the source-code. E.g the
> source 
>    #if 0
>       int a;
>    #endif
> will yield an empty IASTTranslationUnit.

Thanks for taking the time to reply.

What you describe is what I expected, but it is not consistent with what
the DOM visualizer shows. For example, in the Coyotos kernel, we have
some enumerations that are built with macros so that corresponding
switch statement emission and enum-driven procedure dispatch can be
automated. If an example is helpful, here are the macro definitions

http://dev.eros-os.com/hg/coyotos/trunk/file/10cf349e720a/src/sys/obstore/captype.def

and the corresponding switch-based procedure dispatch table is at:

http://dev.eros-os.com/hg/coyotos/trunk/file/10cf349e720a/src/sys/kernel/kern_Process.c

However, when I bring up kern_Process.c in the DOM visualizer, what I
see here is IASTPreprocessor... nodes. Also, when I look at the call
graph using the full indexer, the procedures that are called from the
switch statement in do_cap_invocation() are not shown (which they should
be if expansion is occuring). Perhaps I am using the wrong visualizer.

Since this is a cross compile, it is also possible that I have not
configured the name of the gcc compiler in a way that the make output
parser recognizes as a compiler invocation.

It is also possible (this only just occurred to me now) that ccache is
confusing the parser, because our compile lines all look like:

  /usr/bin/ccache /coyotos/host/bin/i386-unknown-coyotos-gcc ...args...

I tried changing the build target under Behavior to

	COYOTOS_CCACHE="" install

to suppress the use of ccache. That got me some complaints from /bin/sh,
and looking at the output in the Console window it is obvious that the
variable change is not getting propagated to the invocation of make in
the build directory. Is there a way to ensure that this variable is
propagated to the build?

I also tried telling the scanner that the compiler name was

  /usr/bin/ccache /coyotos/host/bin/i386-unknown-coyotos-gcc

(with space). I figured that was a long shot, but it couldn't hurt to
try it. No joy.

So at this point I'm trying to understand a bit better how the make
output parser works, how to understand what the existing parser *thinks*
is going on. Also, I'm trying to understand what output I should be
expecting, so that I can tell the difference between intended behavior
and the expected challenges of a complex, monster build (which,
admittedly, shouldn't have been my first test case :-).

I can rework our build system so that ccache can be configured out of
the build and see if that helps, but I'ld still like to know how to get
some hints from the various CDT parsers about what they believe is
happening here.


shap



Back to the top