[Gc] gc make fail on Solaris 10 x86_64 with gcc-3.* & -m64 option

Kiyoshi KANAZAWA yoi_no_myoujou at yahoo.co.jp
Thu Mar 29 03:37:41 PST 2012


Hi, Ivan,

About libatomic_ops/master with gcc-4.4.7 -m32:
Coredump seems to be caused by AO_compare_double_and_swap_double_full.
I used Sun dbx (gdb does not accept "ELF 32-bit" format produced by /usr/ccs/bin/ld).
% dbx test_atomic
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.9' in your .dbxrc
Reading test_atomic
Reading ld.so.1
Reading libpthread.so.1
Reading libc.so.1
(dbx) run                                                                    
Running: test_atomic 
(process id 29080)
t at 1 (l at 1) signal SEGV (no mapping at the fault address) in AO_compare_double_and_swap_double_full at line 193 in file "x86.h"
  193     __asm__ __volatile__("xchg %%ebx,%6;" /* swap GOT ptr and new_val1 */

By the way, "master" branch does not require "--enable-threads=posix", right ?
./configure says "configure: WARNING: unrecognized options: --enable-threads"


I checked "release" branch with "./configure --enable-threads=posix" again.
(gcc-3.4.3, gcc-4.4.7, gcc-4.6.3, solarisstudio12.3, solstudio12.2), (-m32, -m64).
All the combination passed make & make check.

Regards,

--- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>



--- On Thu, 2012/3/29, Ivan Maidanski <ivmai at mail.ru> wrote:

> Hi Kiyoshi,
> 
> I've finally understand why do you fail with bdwgc if using Sun CC.
> 
> Here is how to invoke configure:
> CC=cc CFLAGS="-xO3 ... -DGC_THREADS" ./configure
> ...
> checking for thread model used by GCC... no
> ...
> linking without pthread_support.o -> linkage error
> 
> This is wrong, the correct way is:
> CC=cc CFLAGS="-xO3 ..." ./configure --enable-threads=posix
> 
> This is caused by the fact, that configure auto-detects threading model by parsing compiler output expecting the compiler is GCC, if it fails it assumes no MT support.
> 
> I've updated README.solaris2: https://github.com/ivmai/bdwgc/commit/cfca1cca99c757ac33c114ad3e9dd77ef430c0fa
> 
> PS. Still you have undiagnosed problem with libatomic_ops/master with gcc-4.4.7 -m32 on Solaris.
> 
> Regards.
> 
> Wed, 28 Mar 2012 19:32:24 +0400 Ivan Maidanski <ivmai at mail.ru>:
> > Hi Kiyoshi,
> > 
> > Wed, 28 Mar 2012 21:05:09 +0900 (JST) Kiyoshi KANAZAWA <yoi_no_myoujou at yahoo.co.jp>:
> > > Hi, Ivan,
> > > 
> > > According to ChangeLog,
> > > "release" is 7.2alpha6 + changes from 2011-06-15 to 2012-03-26.
> > 
> > Yes, correct. This is 7.2 final release candidate (it is not released, so the version from release branch is 7.2alpha7 snapshot).
> > 
> > > "master" is [7.3alpha2] (development)
> > 
> > This is 7.3alpha2 release candidate (again, it is not released, so the version from master branch is 7.3alpha1 snapshot).
> > Finally, on release, "development" word would be replaced with exact date.
> > 
> > > The answer to your question:
> > > > You are checking "master" branch of libatomic_ops (v7.3alpha1), right?
> > > is No. Later one.
> > 
> > I've asked you because there 2 libs (bdwgc and libatomic_ops) and both have 2 versions planned for releasing (more stable 7.2 ("release" branch) and a development alpha 7.3 contained in "master" branch of Git repo). In the first case (1) you had reported about bdwgc-7.2 and in (2) you had reported about libatomic_ops-7.3alpha, it looked strange to me (why not to test to libs of the same version) - so I've asked you whether there were no problems with bdwgc-7.3alpha and libatomic_ops-7.2 or you just skipped their testing for now. (I'm really sorry for giving 2x2 libs in total to test and probably confusing you.)
> > 
> > > 
> > > 
> > > (1) release
> > > (1.1) suggestion
> > > OK. I misunderstood as if GC_SOLARIS_THREADS and GC_THREADS were completely different.
> > > (1.2) test result by gcc
> > > Nothing to mention.
> > > (1.3) test result with Oracle cc
> > > I may try to make it conditional, but it needs time.
> > > And I'm re-building all the NGU software I use. Much more time I need.
> > > 
> > > (2) master
> > > > What about "release" branch of it (is it working or the same problem, or has not been tested)?
> > > As mentioned in (1), no same problem in "release" branch.
> > 
> > My test Solaris environment is:
> > Solaris 10u9 x86
> > gcc version 3.4.6 (x86)
> > cc: Sun C 5.11 SunOS_i386 2010/08/13
> > 
> > I tested libatomic_ops (both release and master) with gcc, cc -m32, cc -m64. It succeeded.
> > 
> > > I'll try gdb for "master" branch later.
> > > 
> > > By the way, it is written  "Require automake 2.61 instead of v2.64." in [7.3alpha2] ChangeLog.
> > > The latest version I can find is automake-1.11.3.
> > 
> > Thanks for spotting it - the correct is autoconf 2.61 (I'll change master ChangeLog in both bdwgc and libatomic_ops).
> > 
> > > Do I need another one to test "master" branch ?
> > 
> > I've just improved -fPIC processing in configure (libatomic_ops in both release and master branches). As your reported you succeeded with libatomic_ops-7.2 but failed wit libatomic_ops-7.3alpha, I don't thing my recent commit fixes the bug in test_atomic on your side (but nonetheless, please try).
> > 
> > > 
> > > Regards,
> > > 
> > > --- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>
> > > 
> > > 
> > > --- On Wed, 2012/3/28, Ivan Maidanski <ivmai at mail.ru> wrote:
> > > 
> > > > Hi Kiyoshi,
> > > > 
> > > > Tue, 27 Mar 2012 23:53:27 +0900 (JST) Kiyoshi KANAZAWA <yoi_no_myoujou at yahoo.co.jp>:
> > > > > Hi, Ivan,
> > > > > 
> > > > > Done without Git.
> > > > > 
> > > > > (1) release
> > > > 
> > > > To be precise, you testing "release" branch of BDWGC (gc7.2) here.
> > > > 
> > > > > (1.1) suggestion
> > > > > I guess it is better to set -DGC_THREADS for Solaris by default.
> > > > > There was choice -DGC_SOLARIS_THREADS (thr_ functions) or -DGC_THREADS in gc-7.1.
> > > > 
> > > > No, GC_SOLARIS_THREADS is a synonym of GC_THREADS on Solaris.
> > > > (i.e., now it does not mean that thr_ interface is used)
> > > > 
> > > > > Now, it is said in doc/README.solaris2 that
> > > > >   SOLARIS THREADS:
> > > > >   The collector must be compiled with -DGC_THREADS to be thread safe.
> > > > >   This assumes use of the pthread_ interface.  Old style Solaris threads
> > > > >   are no longer supported.
> > > > 
> > > > The doc is correct.
> > > > 
> > > > > 
> > > > > (1.2) test result by gcc
> > > > > make & make check passed with all the combination of
> > > > > (gcc-3.4.3, gcc-4.4.7, gcc-4.6.3) (-m32, -m64)
> > > > > 
> > > > > (1.3) test result with Oracle cc
> > > > > Tried also Oracle cc (solstudio12.2, solarisstudio12.3), and found
> > > > > make check fails (both -m32 & -m64).
> > > > > It might be caused by some compile switches.
> > > > > Error message is such as
> > > > > libtool: link: cc -I/tmp/ivmai-bdwgc-aee0d2b -xarch=sse4_1 -xchip=core2 -xO3 -DGC_THREADS -m32 -I/usr/local/GNU/include -L/usr/local/GNU/lib -G -z defs -h libgc.so.1 -o .libs/libgc.so.1.0.3  .libs/allchblk.o .libs/alloc.o .libs/blacklst.o .libs/checksums.o .libs/dbg_mlc.o .libs/dyn_load.o .libs/finalize.o .libs/gc_dlopen.o .libs/gcj_mlc.o .libs/headers.o .libs/malloc.o .libs/mallocx.o .libs/mark.o .libs/mark_rts.o .libs/misc.o .libs/new_hblk.o .libs/obj_map.o .libs/os_dep.o .libs/pcr_interface.o .libs/ptr_chck.o .libs/real_malloc.o .libs/reclaim.o .libs/specific.o .libs/stubborn.o .libs/typd_mlc.o .libs/backgraph.o .libs/thread_local_alloc.o .libs/mach_dep.o   -L/usr/local/GNU/lib -ldl -lc  -xarch=sse4_1 -m32  
> > > > > Undefined                       first referenced
> > > > >  symbol                             in file
> > > > > GC_start_world                      .libs/alloc.o
> > > > > ..
> > > > > ld: fatal: symbol referencing errors. No output written to .libs/libgc.so.1.0.3
> > > > > make[1]: *** [libgc.la] Error 2
> > > > > make[1]: Target `all-am' not remade because of errors.
> > > > > make[1]: Leaving directory `/tmp/ivmai-bdwgc-aee0d2b'
> > > > > make: *** [all-recursive] Error 1
> > > > > make: Target `all' not remade because of errors.
> > > > > make[1]: Entering directory `/tmp/ivmai-bdwgc-aee0d2b'
> > > > 
> > > > Looks like PTHREADS AM conditional is undefined (checked in Makefile.am) thus pthread_support.c is not compiled/linked.
> > > > Please, if possible, investigate the problem with PTHREADS AM. 
> > > > 
> > > > > 
> > > > > 
> > > > > (2) master
> > > > 
> > > > You are checking "master" branch of libatomic_ops (v7.3alpha1), right?
> > > > What about "release" branch of it (is it working or the same problem, or has not been tested)?
> > > > 
> > > > > It is confusing.
> > > > > make & make check passed with
> > > > > (gcc-3.4.3, gcc-4.6.3,  solstudio12.2 cc , solarisstudio12.3 cc) (-m32, -m64)
> > > > > and (gcc-4.4.7)  (-m64),
> > > > > but make check fails only with (gcc-4.4.7) (-m32).
> > > > > 
> > > > > libtool: link: gcc -I/tmp/ivmai-master -mtune=core2 -msse3 -mfpmath=sse -O2 -m32 -I/usr/local/GNU/include -Wall -Wextra -D__PIC__=1 -g -O2 -o test_malloc test_malloc.o  -L/usr/local/GNU/lib -lpthread ../src/.libs/libatomic_ops_gpl.a ../src/.libs/libatomic_ops.a
> > > > > make[3]: Leaving directory `/tmp/ivmai-master/tests'
> > > > > make  check-TESTS
> > > > > make[3]: Entering directory `/tmp/ivmai-master/tests'
> > > > > /bin/bash: line 5: 16359 Segmentation Fault      ${dir}$tst
> > > > > FAIL: test_atomic
> > > > 
> > > > Looks like a compiler bug. We could probably make a workaround
> > > > Could you please run it under gdb and tell me exact source line of Seg Fault?
> > > > 
> > > > > Missing: AO_nop_acquire
> > > > > Missing: AO_store_acquire
> > > > > Missing: AO_short_store_acquire
> > > > > Missing: AO_char_store_acquire
> > > > > Missing: AO_int_store_acquire
> > > > > Missing: AO_nop_release
> > > > > Missing: AO_load_release
> > > > > Missing: AO_short_load_release
> > > > > Missing: AO_char_load_release
> > > > > Missing: AO_int_load_release
> > > > > Missing: AO_store_read
> > > > > Missing: AO_short_store_read
> > > > > Missing: AO_char_store_read
> > > > > Missing: AO_int_store_read
> > > > > Missing: AO_load_write
> > > > > Missing: AO_short_load_write
> > > > > Missing: AO_char_load_write
> > > > > Missing: AO_int_load_write
> > > > > Missing: AO_nop_release_write
> > > > > Missing: AO_load_release_write
> > > > > Missing: AO_short_load_release_write
> > > > > Missing: AO_char_load_release_write
> > > > > Missing: AO_int_load_release_write
> > > > > Missing: AO_nop_acquire_read
> > > > > Missing: AO_store_acquire_read
> > > > > Missing: AO_short_store_acquire_read
> > > > > Missing: AO_char_store_acquire_read
> > > > > Missing: AO_int_store_acquire_read
> > > > > Testing add1/sub1
> > > > > Succeeded
> > > > > 
> > > > > I do not know what "Missing: AO..." mean, but they are found also in cases make check pass.
> > > > 
> > > > Missing AO_XXX is normal.
> > > > 
> > > > Regards.
> > > > 
> > > > > 
> > > > > --- Kiyosih <yoi_no_myoujou at yahoo.co.jp>
> > > > > 
> > > > > 
> > > > > --- On Tue, 2012/3/27, Ivan Maidanski <ivmai at mail.ru> wrote:
> > > > > 
> > > > > > Hi Kiyoshi,
> > > > > > 
> > > > > > Tue, 27 Mar 2012 06:27:04 +0900 (JST) Kiyoshi KANAZAWA <yoi_no_myoujou at yahoo.co.jp>:
> > > > > > > > Everything is OK now.
> > > > > > > > I tested all the combination of
> > > > > > > > (gcc-4.6.3, gcc-4.4.7, gcc-4.6.3), (-m32, -m64), (gc-7.1, gc-7.2alpha6).
> > > > > > > 
> > > > > > > wong: (gcc-4.6.3, gcc-4.4.7, gcc-4.6.3)
> > > > > > > correct  (gcc-3.4.3, gcc-4.4.7, gcc-4.6.3)
> > > > > > > 
> > > > > > > --- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>
> > > > > > > 
> > > > > > 
> > > > > > Would also be good if you test recent BDWGC/libatomic_ops snapshots instead of gc-7.1/7.2alpha6:
> > > > > > 
> > > > > > In case you don't use Git, to test the recent "release" branch snapshot (corresponding to 7.2 final candidate):
> > > > > > 
> > > > > > wget https://github.com/ivmai/bdwgc/zipball/release
> > > > > > unzip release
> > > > > > cd ivmai-bdwgc-*/
> > > > > > wget https://github.com/ivmai/libatomic_ops/zipball/release
> > > > > > unzip release
> > > > > > mv ivmai-libatomic_ops-* libatomic_ops
> > > > > > ./configure
> > > > > > make check
> > > > > > 
> > > > > > The same for "master" branch (corresponding to 7.3alpha2 candidate): just replace "release" with "master" and call ./autogen.sh before ./configure
> > > > > > 
> > > > > > Regards.
> > > > > >
> > > > >
> > > 



More information about the Gc mailing list