> When you say Windows, do you mean cygwin? I would expect that any
> remotely normal Unix linking operation would work there.

Good question. I guess in phase 1 I mean cygwin, and in phase 2 I mean
pure msvc build environment. It might be even that phase 2 is not
reachable
- because a lot of gcc tree macros.

Now I have tried to recall what problems I've came across when
compiling
de-hydra...
First of all - spider monkey is built according to this instructions:
http://pmelson.blogspot.com/2007/12/building-didier-stevens-spidermonkey-in.html

and I'm not sure whether it's built correctly or not - shared objects
in cygwin are windows
dlls - meanwhile spidermonkey has library format.

Then I've managed to configure dehydra correctly:

$ ./configure --js-libs=../../mozilla/js/src/Linux_All_DBG.OBJ --js-
headers=/cy
gdrive/c/projects6/code_analysis/mozilla/js/src --gcc-build=/cygdrive/
c/project
s6/code_analysis/gcc-dehydra/gcc-build2

and build goes through compilation phase but fails on linking:

dehydra_plugin.o: In function `dfs_process_chain':
/cygdrive/c/projects6/code_analysis/dehydra_clean/dehydra-0.9/
dehydra_plugin.c:29: undefined reference to `_tree_code_type'
/cygdrive/c/projects6/code_analysis/dehydra_clean/dehydra-0.9/
dehydra_plugin.c:29: undefined reference to `_fancy_abort'
dehydra_plugin.o: In function `process_template_decl':
/cygdrive/c/projects6/code_analysis/dehydra_clean/dehydra-0.9/
dehydra_plugin.c:35: undefined reference to `_tree_contains_struct'
/cygdrive/c/projects6/code_analysis/dehydra_clean/dehydra-0.9/
dehydra_plugin.c:35: undefined reference to
`_tree_contains_struct_check_failed'

....
....

I've tried to apply patch similar to spider monkey - by replacing
-shared option with -r option (config.mk:
SHARED_LINK_FLAGS=-shared
=>
SHARED_LINK_FLAGS=-r
) - but without success. (Same error messages).

I'm not familiar with -r parameter - and could not locate it in
documentation
- I by myself has always used -shared parameter. So I've decided to go
deeper
into dehydra plugin source code. I need to study tree walking and tree
management anyway.


> I happen to think that Dehydra and the Treehydra libs are relatively
> readable examples of GCC API client code. See the libs/ and test/
> directory in the Dehydra dist.

I believe in that as well. I'm bit familiar with java by myself, but
it was long time
when I've last time made java classes.

> There is GCC documentation on the trees as well, but I would need to
> know what kind of intermediate representations you want in order to know
> where you need to look. For the basics, tree.def and cp/cp-tree.def are
> the places to go. There is also the GCC Internals manual. Finally, there
> are some useful PDFs from Diego Novillo out there. I forget where to
> find them all but you can start 
> withhttp://www.google.com/search?q=diego+novillo+gcc+internals

Partially familiar, partially will try to read more.

> > Ok. So dehydra plugin is bound to c/c++ only. It's not that important
> > anyway ( I can survive with c/c++).
> > Do you know why gcc is compiled in such manner - libbackend is
> > separated from front ends ?
> > Is there any way I can pick up global_namespace parameter from
> > backend ?
> > Or may be backend should have some function to call frontend
> > functions. How they communicate anyway ?
>
> I'm not sure what's going on here. I see that in Dehydra, gcc_compat.h
> defines global_namespace as a weak symbol, so it should not result in a
> linker error if it cannot be found. Instead it should just have the
> value 0 or something.

I haven't found any declaration of global_namespace in dehydra. Have
you done
any updates on top of 0.9 version ?

I'm trying to pass global_namespace from gcc
(by altering tree-plugin-pass.c source code - see my previous posts)

May be I'll try to define it as weak symbol as well, if I'll find some
documentation
how it's done. (I'll do some googling).

> > Do you know bit more details about gcc trees - are they always in
> > ram ?
> > (E.g. can leaves be loaded on demand ?)
>
> See above on GCC internals in general.
>
> On memory management: The trees are always in memory. In treehydra, the
> JS objects representing GCC tree nodes are created on demand. GCC is
> strictly file-at-a-time (although WPO will change that in some way I'm
> not too clear on).

Google on "WPO" gives something like: World Packaging Organisation.
I guess it's not something you're telling me ? :)

> When we do general interprocedural analyses, we use 2
> phases: one with gcc plugins that extracts sufficient summary
> information on each element in each file, then an aggregation phase that
> puts it all together.

gcc perform some internal tuning of "code tree" -  so is this
something to do
phasing ?

There exists 6 functions which are called between gcc and dehydra. Is
there any
description about these functions ? May be you can describe their call
order and parameters
shortly ?

I'm probably intrested only in first phase, since I will need to
perform reverse operation
at some point of time - trees back to source code. (Pretty printing of
code trees ? :) )
_______________________________________________
dev-static-analysis mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-static-analysis

Reply via email to