hi i'm trying to link libgcj dll for cygwin. at recent, i get error while creating classmap.db but it is wonder why this happened. it has been worked well though.... when gcj-dbtool is static-linked to libgcj it doesn't give errors. (it doesn't confine to gcj-dbtool. every program to linked libgcj.dll makes this error.) Program received signal SIGSEGV, Segmentation fault. 0x6bf1da9e in _Jv_Linker::verify_class (klass=<value optimized out>, state=<value optimized out>) at ../.././libjava/link.cc:1904 1904 klass->engine->verify(klass); (gdb) bt #0 0x6bf1da9e in _Jv_Linker::verify_class (klass=<value optimized out>, state=<value optimized out>) at ../.././libjava/link.cc:1904 #1 _Jv_Linker::wait_for_state (klass=<value optimized out>, state=<value optimized out>) at ../.././libjava/link.cc:2074 #2 0x6bf496e8 in java::lang::Class::initializeClass ( this=<value optimized out>) at ../.././libjava/java/lang/natClass.cc:717 #3 0x6bf103a9 in _Jv_InitClass (vm_args=<value optimized out>) at ../.././libjava/prims.cc:1666 #4 _Jv_CreateJavaVM (vm_args=<value optimized out>) at ../.././libjava/prims.cc:1666 #5 0x6bf103ec in _Jv_RunMain (vm_args=<value optimized out>, klass=<value optimized out>, name=<value optimized out>, argc=<value optimized out>, argv=<value optimized out>, is_jar=<value optimized out>) at ../.././libjava/prims.cc:1719 #6 0x6bf10738 in _Jv_RunMain (klass=<value optimized out>, name=<value optimized out>, argc=<value optimized out>, argv=<value optimized out>, is_jar=<value optimized out>) at ../.././libjava/prims.cc:1814 #7 0x6bf107af in JvRunMain (klass=<value optimized out>, argc=<value optimized out>, argv=<value optimized out>) at ../.././libjava/prims.cc:1820 #8 0x00401152 in _fu0___Jv_Compiler_Properties (argc=<value optimized out>, argv=<value optimized out>) at /cygdrive/d/Temp/cache/ccyGFL1n.i:11
here is vtable dump for klass as you can see , klass->engine of dynamic version is NULL whereas static version got proper instance though.... so klass->engine->verify(klass); invokes SEGV....... but why does it happened??? some linker problem?? $ diff static dynamic -ud --- static 2010-01-09 02:43:35.750000000 +0900 +++ dynamic 2010-01-09 02:43:36.187500000 +0900 @@ -1,23 +1,23 @@ (gdb) print *klass -$1 = (java::lang::Class) { +$2 = (java::lang::Class) { <> = {<No data fields>}, members of java::lang::Class: static class$ = { <> = {<No data fields>}, members of java::lang::Class: static class$ = <same as static member of an already seen type>, - next_or_version = 0x0, - name = 0xe2e9f4, + next_or_version = 0x40062e08, + name = 0x6c7f70b4, accflags = 49, - superclass = 0xb5c900, + superclass = 0x6c587100, constants = { size = 37, - tags = 0xb5c180 "", - data = 0xb5c0e0 + tags = 0x6c587580 "", + data = 0x6c5874e0 }, { - methods = 0xb5c1c0, - element_type = 0xb5c1c0 + methods = 0x6c5875c0, + element_type = 0x6c5875c0 }, method_count = 82, vtable_method_count = 65, @@ -26,15 +26,15 @@ ---Type <return> to continue, or q <return> to quit--- field_count = 0, static_field_count = 0, - vtable = 0xb5bf28, + vtable = 0x6c587328, otable = 0x0, otable_syms = 0x0, atable = 0x0, atable_syms = 0x0, itable = 0x0, itable_syms = 0x0, - catch_classes = 0xb5c828, - interfaces = 0xb5c840, + catch_classes = 0x6c587c28, + interfaces = 0x6c587c40, loader = 0x0, interface_count = 4, state = 1 '\001', @@ -52,37 +52,37 @@ hack_signers = 0x0, chain = 0x0, aux_info = 0x0, - engine = 0x1173040, - reflection_data = 0xe2ea20 "\001" + engine = 0x0, + reflection_data = 0x6c7f70e0 "\001" }, - next_or_version = 0x0, - name = 0xdfea20, + next_or_version = 0x40062e08, + name = 0x6c8cb860, accflags = 1057, - superclass = 0xb5c900, + superclass = 0x6c587100, constants = { size = 24, - tags = 0xb1c838 "", - data = 0xb19d00 + tags = 0x6c6a12d8 "", + data = 0x6c69e7a0 }, { - methods = 0xb1c860, - element_type = 0xb1c860 + methods = 0x6c6a1300, + element_type = 0x6c6a1300 }, method_count = 37, vtable_method_count = 34, - fields = 0xb1cb60, + fields = 0x6c6a1600, size_in_bytes = 44, field_count = 13, ---Type <return> to continue, or q <return> to quit--- static_field_count = 4, - vtable = 0xb13888, + vtable = 0x6c698328, otable = 0x0, otable_syms = 0x0, atable = 0x0, atable_syms = 0x0, itable = 0x0, itable_syms = 0x0, - catch_classes = 0xb1cc30, + catch_classes = 0x6c6a16d0, interfaces = 0x0, loader = 0x0, interface_count = 0, @@ -101,6 +101,6 @@ ---Type <return> to continue, or q <return> to quit--- chain = 0x0, aux_info = 0x0, - engine = 0x1173040, - reflection_data = 0xdfea40 "\002" + engine = 0x0, + reflection_data = 0x6c8cb880 "\002" \ No newline at end of file
maybe this could be linker problem. jcr section doesn't seem preserved in shared library. 00ffd668 d ___JCR_LIST__ 010021c4 d ___JCR_END__ 004097b4 d ___JCR_LIST__ 004097c0 d ___JCR_END__
[ Replying to your post on binutils list ] jojelino wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42658 > > it is critical when linking libgcj library hence it uses .jcr section to > initialize java class CTORs > > how can we workaround this phenomenon?? > > $ nm -sn cyggcj-11.dll |grep JCR > 6c9487d0 d ___JCR_END__ > 6c9487d0 d ___JCR_LIST__ I can't reproduce this: after bootstrapping GCC at r.155680, I get: $ nm -sn i686-pc-cygwin/libjava/.libs/cyggcj-11.dll |grep JCR 6c93ecd0 d ___JCR_LIST__ 6c94382c d ___JCR_END__ Also, gcj-dbtool works for me: $ PATH=./i686-pc-cygwin/libjava/.libs:$PATH ./i686-pc-cygwin/libjava/.libs/gcj -dbtool.exe --help gcj-dbtool: Manipulate gcj map database files Usage: gcj-dbtool -n file.gcjdb [size] - Create a new gcj map database gcj-dbtool -a file.gcjdb file.jar file.so - Add the contents of file.jar to a gcj map database gcj-dbtool -f file.gcjdb file.jar file.so - Add the contents of file.jar to a gcj map database gcj-dbtool -t file.gcjdb - Test a gcj map database gcj-dbtool -l file.gcjdb - List a gcj map database gcj-dbtool [-][-0] -m dest.gcjdb [source.gcjdb]... - Merge gcj map databases into dest Replaces dest To add to dest, include dest in the list of sources If the first arg is -, read the list from stdin If the first arg is -0, filenames separated by nul gcj-dbtool -p [LIBDIR] - Print default database name What version of binutils are you using, and how do you configure your GCC build?
Created attachment 19517 [details] diff file i used here is configuration ./configure --prefix=/usr --disable-win32-registry --enable-threads=posix --enable-languages=c,c++,java --with-win32-nlsapi=unicode --enable-tls --disable-bootstrap --enable-shared --enable-interpreter --disable-sjlj-exceptions --enable-java-awt=gtk
Comment on attachment 19517 [details] diff file i used here is configuration ./configure --prefix=/usr --disable-win32-registry --enable-threads=posix --enable-languages=c,c++,java --with-win32-nlsapi=unicode --enable-tls --disable-bootstrap --enable-shared --enable-interpreter --disable-sjlj-exceptions --enable-java-awt=gtk and i used binutils GNU ld (GNU Binutils) 2.20.51.20100108
(In reply to comment #4) > Created an attachment (id=19517) [edit] > diff file i used I don't like the look of this one: diff --git a/libjava/configure.host b/libjava/configure.host old mode 100644 new mode 100755 index 3baaf27..74aac08 --- a/libjava/configure.host +++ b/libjava/configure.host @@ -353,7 +353,7 @@ case "${host}" in BACKTRACESPEC= # Win32 DLLs are limited to 64k exported symbols each. enable_libgcj_sublibs_default=yes - libgcj_sublib_ltflags='-no-undefined -bindir $(bindir)' + libgcj_sublib_ltflags='-Wl,--export-all-symbols -no-undefined -bindir $(bindir)' I don't know what the intent is of this change. It shouldn't be necessary, I hope, and one possible result of exporting all the undesired symbols is that you may have pushed the number of exports from the dll over 65535, which breaks it. Can you please run "objdump -p cyggcj-11.dll > hdrs.txt" and attach hdrs.txt to the PR?
Created attachment 19520 [details] gzipped text oh my. it counts more than 65535.. [167929] and gzipped file exceed limit 1000k so i can't attach it at once. --export-all-symbols was added because of undefined symbol error.
(In reply to comment #7) > Created an attachment (id=19520) [edit] > gzipped text > > oh my. it counts more than 65535.. [167929] !LOL! That's rather a lot! > and gzipped file exceed limit 1000k so i can't attach it at once. No, OK, never mind; we have found the problem! > --export-all-symbols was added because of undefined symbol error. Well it is the wrong answer; as you can see it is too crude. It is vital that the version script is applied to filter out the undesired symbols from being exported. Where did the undefined symbols come from? They must also be a result of that patch somehow, no? Do you get any problem at all from plain unmodified GCC head?
Comment on attachment 19520 [details] gzipped text oh my i ran objdump -t instead of objdump -p i'm sorry for this.
Created attachment 19521 [details] undefined symbol list this is undefined symbol list when i link without --export-all-symbols when linking libgcj-noncore.dll
Ah. It's probably caused by --enable-java-awt. AWT isn't yet supported on cygwin yet; looks like it will need some adjustment to the way .o files are divided between the two dlls, most likely. Can you confirm whether or not you get this bug with completely clean unmodified sources? I'm guessing that, without your patch to configure, it would have errored out with the option present?
(In reply to comment #11) > Ah. It's probably caused by --enable-java-awt. AWT isn't yet supported on > cygwin yet; looks like it will need some adjustment to the way .o files are > divided between the two dlls, most likely. > > Can you confirm whether or not you get this bug with completely clean > unmodified sources? I'm guessing that, without your patch to configure, it > would have errored out with the option present? > whenever i fetch gcc from git, i must run git reset --hard so it will be unmodified source at first. after that, i apply these patches. unless it doesn't compile at all ;<
Created attachment 19522 [details] hdrs (with --export-all-symbols) which i should have attached it counts 57439 whoa, what happens if total number of export symbols of dlls exceed 65535? i'm just curious about it.
(In reply to comment #12) > (In reply to comment #11) > > Ah. It's probably caused by --enable-java-awt. AWT isn't yet supported on > > cygwin yet; looks like it will need some adjustment to the way .o files are > > divided between the two dlls, most likely. > > > > Can you confirm whether or not you get this bug with completely clean > > unmodified sources? I'm guessing that, without your patch to configure, it > > would have errored out with the option present? > > > > whenever i fetch gcc from git, i must run git reset --hard so it will be > unmodified source at first. after that, i apply these patches. > unless it doesn't compile at all ;< Well, I don't use the git repository, and it isn't the source from which releases are taken, and it often gets broken. So it might not be a real bug in the main gcc sources in svn. I'll try building the svn version with your configure line and see what happens. (In reply to comment #13) > Created an attachment (id=19522) [edit] > hdrs (with --export-all-symbols) which i should have attached > > it counts 57439 whoa, > what happens if total number of export symbols of dlls exceed 65535? > i'm just curious about it. Total disaster. Attempts to access exports >65536 wrap round. Can end up jumping into random places or loading from invalid memory addreses or almost anything. Usually dies in early startup.
just waiting to see if this can be reproduced with clean sources.
Confirmed that it was just a glitch of some kind.