Tarmik wrote:
There exists links to gcc source code - and correct me if I'm wrong -
but linux linker can export symbols missing in dehydra plugin from gcc
itself.
In windows however it's not possible - so because of that those global
variables needs to be passed by gcc to de-hydra plugin.
I've tried something similar - put global_namespace into tree-plugin-
pass.c, but then it results in linker error:
tree-plugin-pass.c:156: undefined reference to `_global_namespace'
Yeah, normally on windows you need to make a .def file or something with
all of the symbols you want to share..Just dump every gcc symbol in
there to replicate linux behavior. Howevercygwinshould emulate enough
of linux to not need that...Are you sure you are loading the plugin into
the C++ compiler?
I've not able to compile de-hydra plugin at all in cygwin. Using gcc
some version
(Now after make install - it's 4.3 customized for dehydra)
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 ;)
May be we can exchange some mail on who is doing and what, and I could
assist porting de-hydra tocygwin.
Ok.
Several questions:
- 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.
I've tried to add following pieces of code:
tree-plugin-pass.c:
static void init(void) {
...
gcc_plugin_func fptr_plugin_pass;
gcc_plugin_func fptr_plugin_finish;
gcc_plugin_set_param fptr_set_param;
} u;
char *prior_plugin_name = (char*) "useless";
...
fptr_plugin_finish_struct = u.fptr_finish_struct;
u.vptr = dlsym(handle, str_plugin_finish);
fptr_plugin_finish = u.fptr_plugin_finish;
u.vptr = dlsym(handle, "gcc_plugin_set_param");
if(u.vptr)
{
u.fptr_set_param(0,(void*) global_namespace);
} //if
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.
Now I'm pretty much guessing here - but it might be a part of
frontend.a, and
plugin is part of back end - causing this kind of problem ?!
Can you direct me to place from where you're picked up information
about global_namespace ?
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.
Taras
_______________________________________________
dev-static-analysis mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-static-analysis
