> The latter document mentions that they got a lot of strange linker
> errors that went away when they changed the .so extension in their
> Makefiles to .dll. This will not solve the weak symbol issue but I think
> it may fix some of the other problems you've seen.
In NULL plugin I've already done that. But amount of errors did not
decrease
because of that. (If I recall correctly).
> I wouldn't worry
> about the weak symbol thing until you have the rest of it straightened out.
The main problem is not only with 'global_namespace'. All weird
symbols - like
fancy_abort, etc... coming through tree macros which are used by
dehydra.
For example tree.h:
#define TREE_CODE_CLASS(CODE) tree_code_type[(int) (CODE)]
-> ends up as undefined 'tree_code_type' symbol.
Btw - what is the story behind 'tree_code_type' - I've found reference
of it
in useful_arrays.c - but that file is not linked in dehydra -
presumably comes
from gcc ?
> If the weak symbol thing is still a problem after you've fixed the other
> errors, I think the fix is to create a patch for Treehydra so that under
> Cygwin builds for C it does not try to use weak symbols, but just uses
> the local Treehydra definition of global_namespace always.
Yes, that what I would like to do next.
I've already modified tree-plugin-pass.c:
---------------------------------------------------------------------------
// Tarmo: Added
typedef int (*gcc_plugin_set_param)(int iArg,void* pParamValue);
...
// Tarmo: Added
static gcc_plugin_set_param fptr_plugin_set_param=NULL;
...
u.vptr = dlsym(handle, str_plugin_finish);
fptr_plugin_finish = u.fptr_plugin_finish;
// Tarmo: Added
u.vptr = dlsym(handle, "gcc_plugin_set_param");
fptr_plugin_set_param = u.fptr_set_param;
...
void plugin_set_param(int iArg, void* pValue)
{
printf("-> plugin_set_param(%d)\n", iArg);
if(fptr_plugin_set_param)
{
fptr_plugin_set_param(iArg,pValue);
}else
{
printf("Error: fptr_plugin_set_param is NULL\n");
} //if-else
} //plugin_set_param
And modified cp/cp-lang.c:
static void
cp_init_ts (void)
{
...
// Tarmo: Added.
plugin_set_param(0,global_namespace);
}
I have figured out that cp-lang.c is main code which initializes c/c++
frontend,
and it could pass 'global_namespace' to plugin.
During make command I can even see that this function chain is
called,
however - I have some problems with cp-lang.c modification does not
end
up into gcc.exe (even through it end up into cc1.exe and libbackend.a)
I suspect some rebuildability issue - would not like to run "make
clean"
and "make" with every tiny modification. Will study it bit deeper.
> > I have several practical questions about gcc compilation -
>
> > 1. how to make it faster ?
> > Apparently "make" will try to rebuild everything including standard
> > libraries,
> > meanwhile I'm intrested only in building gcc executables.
>
> I don't know the exact answer to this question, but you may find some
> guidance fromhttp://gcc.gnu.org/install/build.htmland the output of
> ./configure --help. You could probably get an answer pretty quickly on
> the #gcc IRC channel on irc.oftc.net.
Ok. But has you done gcc modifications by yourself ?
Or did you survive with make ?
> > How many CIL users there are ? If over 1000 then I'll probably check
> > it through bit deeper.
> > :)
>
> No idea, but you might get some idea of the user base from their mailing
> list traffic:http://sourceforge.net/mailarchive/forum.php?forum_name=cil-users
Approximately 3-4 messages per month. Sounds like dead language.
_______________________________________________
dev-static-analysis mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-static-analysis
