Tarmik wrote:
Normally in linking procedure "client" application (in dehydra case -
it's gcc)
attaches itself to "server" shared object (dehydra plugin), which
exports certain functions.
In dehydra case dehydra plugin also imports certain global variables
and functions from gcc.
Never saw this kind of thinks happening before. (I'm familiar with
windows, linux, symbian linking procedures)
errno is another popular example of linking variables ;)
If I recall correctly errno is define which resolves to function call
and picks up reference
from return value(pointer). Anyway - such cross linking is not
available (I think)
in windows, and I'm into windows, because msvc debugger is slightly
better than ddd.
On my Linux, it appears that errno was a variable, but on new GCCs is a
function, but just so that it can be thread-local.
When you say Windows, do you mean cygwin? I would expect that any
remotely normal Unix linking operation would work there.
- From which page/docs you have found how to iterate through gcc's
trees ? gcc internal mail lists ?
I've understood that there are several kind of trees - you're using
front end tree, there also exists backend trees ?
(gimple & so on)
Heh. By reading lots of random code :) gccxml was a useful startingpoint
for me.
That's what I was afraid of. :)
Checked through gccxml and it dumps out functions / structures into
xml file,
however - it has nothing to do with gcc's internal trees. If I recall
correctly there were some
options to "pretty print" gcc trees, but unfortunately I don't
remember what options I need to use.
May be you know ?
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.
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 with
http://www.google.com/search?q=diego+novillo+gcc+internals
However - after that gcc cannot be linked anymore:
tree-plugin-pass.c:156: undefined reference to `_global_namespace'
global_namespace does not exits.
Pay attention. global_namespace is something the C++ frontend(cp/
supdirectory). It doesn't exist in the other frontends.
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. So as a start you can try to figure out why it's
not being handled correctly on your system. I also see that it is
defined in util.h so presumably that's supposed to be overridden if it
exists somewhere else or something.
Failing that, you could get off the ground by making a local patch that
removes the references to global_namespace; Dehydra won't do much
without it but Treehydra should work.
I've checked also dehydra_convert2 function, and it references a lot
of different kind of macros - like
TYPE_CONTEXT, TYPE_P, TREE_CODE, IDENTIFIER_POINTER, DECL_NAME.
grep -R is your friend when looking for where something is buried in gcc.
It's quite normal situation that everything new comes without docs /
specs.
That what I was afraid of.
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). 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.
For how long they are retained in ram - e.g. if I'm compiling 1.c,
2.c, 3.c -
will 1.c.tree be present in ram when compiling 2.c ?
I would like to construct a tree similar to gcc, only gcc indepenent.
Btw - you are using java / javascript for accessing data types - java
has quite nice data type reflection system - so it's quite natural to
use java
for reflecting c/c++ data types / functions.
I still haven't tried dehydra plugin in action, since I was bit lazy
to recompile
it in linux (I have redhat linux, but did not yet reach it) - would
like to play with java
for time later on.
_______________________________________________
dev-static-analysis mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-static-analysis
_______________________________________________
dev-static-analysis mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-static-analysis
