> > 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. > > - 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 ? > > 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'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 ?) 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
