Tarmik wrote:
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 ?
I'm fairly sure all these errors have nothing to do with weak symbols.
Rather, it appears that the Cygwin linker, even when creating a DLL,
wants to be able to see all the symbols it will be linking to. This must
be due to a design feature of PE or something.
I tried making a trivial DLL on Cygwin that calls to a function in the
main program, and I got the same error. But when I added the .exe to the
linker command line, it worked. Maybe you can try that. Or try making a
toy version of the linking setup needed for Treehydra. Once you
understand how that has to work, it should not be too hard to figure out
Treehydra. But right now it sounds like you are trying to solve too many
big problems at once.
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.
I've lost track a bit here. You want to use Dehydra with C, in 'gcc',
right? cp-lang.c is only a part of C++, as is global_namespace. So if
you are using C only, then you will never have any value for
global_namespace, so it should just always be 0.
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)
gcc is just a driver program that calls the real preprocessor, compiler,
linker, etc, and just does options processing and file handling.. The
real C compiler is cc1, and the real C++ compiler is cc1plus.
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 ?
I just used 'make'. I haven't had to rebuild GCC too many times. But ask
on IRC. They should know.
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.
CIL is just a library, the language it is implemented in is OCaml. I
believe CIL is not dead, but it is primarily used by programming
languages researchers, which is of course a fairly small group of people.
Dave
_______________________________________________
dev-static-analysis mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-static-analysis
