> 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.
Yes, but this is what weak linking is all about - possibility of
linking whole
dll without having all necessary symbols present. Most probably
limitation
of cygwin and microsoft PE executable format.
> 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.
Intresting idea, newer tried to link against .exe's before. In
theory .exe is dependent on
.dll but it's linked dynamically - that's why we could not have static
links in both direction
- chicken - egg problem. But in one direction static link in another
dynamic link.
Tried to add it like this in Makefile.in:
------------------------------------------------------------------------------------------------------------
GCC_EXE = /cygdrive/c/projects6/code_analysis/gcc-dehydra/gcc-build2/
install/libexec/gcc/i686-pc-cygwin/4.3.0/cc1.exe
DLL_SUFFIX=dll
gcc_dehydra.$(DLL_SUFFIX): dehydra_plugin.o dehydra_builtins.o $
(DEHYDRA_OBJS) $(GCC_EXE)
$(CC) -o $@ $+ $(LDFLAGS)
------------------------------------------------------------------------------------------------------------
After building it results in following errors:
cc -o gcc_dehydra.dll dehydra_plugin.o dehydra_builtins.o
dehydra_ast.o dehydra.o util.o dehydra_types.o /cygdrive/c/projects6/
code_analysis/gcc-dehydra/gcc-build2/install/libexec/gcc/i686-pc-
cygwin/4.3.0/cc1.exe -lm -L/cygdrive/c/projects6/code_analysis/mozilla/
js/src/Linux_All_DBG.OBJ -Wl,-rpath,/cygdrive/c/projects6/
code_analysis/mozilla/js/src/Linux_All_DBG.OBJ,-ljs -shared
/cygdrive/c/projects6/code_analysis/gcc-dehydra/gcc-build2/install/
libexec/gcc/i686-pc-cygwin/4.3.0/cc1.exe:builtins.c:(.text+0x50):
multiple definition of `___gcc_register_frame'
/usr/lib/gcc/i686-pc-cygwin/4.3.0/crtbegin.o:cygming-crtbegin.c:(.text
+0x0): first defined here
/cygdrive/c/projects6/code_analysis/gcc-dehydra/gcc-build2/install/
libexec/gcc/i686-pc-cygwin/4.3.0/cc1.exe:builtins.c:(.text+0x55):
multiple definition of `___gcc_deregister_frame'
/usr/lib/gcc/i686-pc-cygwin/4.3.0/crtbegin.o:cygming-crtbegin.c:(.text
+0x5): first defined here
dehydra_plugin.o: In function `gcc_plugin_post_parse':
/cygdrive/c/projects6/code_analysis/dehydra_2/dehydra-gcc/
dehydra_plugin.c:271: undefined reference to `_global_namespace'
/cygdrive/c/projects6/code_analysis/dehydra_2/dehydra-gcc/
dehydra_plugin.c:272: undefined reference to `_global_namespace'
util.o: In function `isGPlusPlus':
/cygdrive/c/projects6/code_analysis/dehydra_2/dehydra-gcc/util.c:45:
undefined reference to `_global_namespace'
util.o:util.c:(.debug_info+0xaa89): undefined reference to
`_global_namespace'
/usr/lib/gcc/i686-pc-cygwin/4.3.0/../../../../i686-pc-cygwin/bin/ld:
BFD (GNU Binutils) 2.18.50.20080625 assertion fail /netrel/src/
binutils-20080624-2/bfd/cofflink.c:2270
/usr/lib/gcc/i686-pc-cygwin/4.3.0/../../../../i686-pc-cygwin/bin/ld: /
cygdrive/c/projects6/code_analysis/gcc-dehydra/gcc-build2/install/
libexec/gcc/i686-pc-cygwin/4.3.0/cc1.exe(dll_entry.o): illegal symbol
index 1946288346 in relocs
collect2: ld returned 1 exit status
make: *** [gcc_dehydra.dll] Error 1
This is build of latest "hg" snapshoot. 0.9 version gives more errors.
I'm still puzzled why global_namespace remain undefined.
___gcc_(de)register_frame might be CRT (common run-time) part.
Apparently such linking
is not a good alternative either because of double CRTs.
"illegal symbol index" sounds even more intresting since there is
nothing I can do with it.
May be this linking against EXE is not a such good idea after all ?
> > 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.
Actually I have both - c & c++ codes in use, so I would like to parse
them all.
I've assumed that cp-lang.c is responsible for C & C++. But apparently
it is not.
Tried also to compile c++ code, with the same result - cp_init_ts does
not gets called.
Will try to search some other initialization function in c/c++
frontend.
Btw - is gcc/cp/ folder responsible for C also - or only for C++ ?
> 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.
yes, found about it some documentation. So if cc1*.exe gets updated -
I can assume that
compiler code was updated as well. Now I wonder whether "make install"
can be replaced
with "cp cc1.exe ....". Will try that one.
> >> I don't know the exact answer to this question, but you may find some
> >> guidance fromhttp://gcc.gnu.org/install/build.htmlandthe output of
> >> ./configure --help. You could probably get an answer pretty quickly on
> >> the #gcc IRC channel on irc.oftc.net.
Tried to reach irc server but I'm behind quite heavy firewall which
blocks out
all irc ports so unfortunately I have to gave up on irc.
May be gcc-internal mailing list then ?!
> > 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.
Analysis without development does not moves things forward. :)
_______________________________________________
dev-static-analysis mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-static-analysis
