[Gc] gc make fail on Solaris 10 x86_64 with gcc-3.* & -m64
option
Kiyoshi KANAZAWA
yoi_no_myoujou at yahoo.co.jp
Sat Mar 31 22:43:21 PST 2012
I haven't checked bdwgc "master" branch yet.
I'd like to do that after clearing in "release" branch.
GC_SysVGetDataStart passed is:
in guile:
(dbx) print GC_SysVGetDataStart
GC_SysVGetDataStart = &GC_SysVGetDataStart(register size_t max_page_size, register ptr_t etext_addr) at 0xfffffd7fff16f940
in gctest
(dbx) print GC_SysVGetDataStart
GC_SysVGetDataStart = &GC_SysVGetDataStart(register size_t max_page_size, register ptr_t etext_addr) at 0xfffffd7fff31f940
Regards,
--- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>
--- On Sun, 2012/4/1, Ivan Maidanski <ivmai at mail.ru> wrote:
> Hi Kiyoshi,
>
> Sun, 1 Apr 2012 14:28:57 +0900 (JST) Kiyoshi KANAZAWA <yoi_no_myoujou at yahoo.co.jp>:
> > Hi, Ivan,
> >
> > I may encountered some problem again with "release" branch.
>
> Again, do you mean here you haven't checked bdwgc "master" branch or you don't have this problem with it?
>
> >
> > "Segmentation Fault" happened in building guile-2.0.5 with -m64 option.
> >
> > It seems to happen in os_dep.c of GC function:
> > What I checked is:
> > % pwd
> > /tmp/guile-2.0.5/libguile/.libs
> > % ldd guile
> > libguile-2.0.so.22 => /tmp/guile-2.0.5/libguile/.libs/libguile-2.0.so.22
> > libgc.so.1 => /usr/local/GNU/amd64/lib/libgc.so.1
> > libpthread.so.1 => /usr/lib/amd64/libpthread.so.1
> > libdl.so.1 => /usr/lib/amd64/libdl.so.1
> > libffi.so.5 => /usr/local/GNU/amd64/lib/libffi.so.5
> > libintl.so.8 => /usr/local/GNU/amd64/lib/libintl.so.8
> > libc.so.1 => /usr/lib/amd64/libc.so.1
> > libunistring.so.0 => /usr/local/GNU/amd64/lib/libunistring.so.0
> > libiconv.so.2 => /usr/local/GNU/amd64/lib/libiconv.so.2
> > libgmp.so.10 => /usr/local/GNU/amd64/lib/libgmp.so.10
> > libltdl.so.7 => /usr/local/GNU/amd64/lib/libltdl.so.7
> > librt.so.1 => /usr/lib/amd64/librt.so.1
> > libsocket.so.1 => /usr/lib/amd64/libsocket.so.1
> > libnsl.so.1 => /usr/lib/amd64/libnsl.so.1
> > libm.so.2 => /usr/lib/amd64/libm.so.2
> > libgcc_s.so.1 => /usr/local/gcc/lib/amd64/libgcc_s.so.1
> > libaio.so.1 => /usr/lib/amd64/libaio.so.1
> > libmd.so.1 => /usr/lib/amd64/libmd.so.1
> > libmp.so.2 => /usr/lib/amd64/libmp.so.2
> > libscf.so.1 => /usr/lib/amd64/libscf.so.1
> > libdoor.so.1 => /usr/lib/amd64/libdoor.so.1
> > libuutil.so.1 => /usr/lib/amd64/libuutil.so.1
> > libgen.so.1 => /usr/lib/amd64/libgen.so.1
> >
> > libpthread.so.1 is linked to /usr/lib/amd64/libpthread.so.1 in the 3rd line.
> > Is this strange ?
>
> I don't know. What are the alternatives?
>
> >
> > % dbx guile
> > (dbx) run
> > Running: guile
> > (process id 742)
> > t at 1 (l at 1) signal SEGV (no mapping at the fault address) in GC_SysVGetDataStart at line 1859 in file "os_dep.c"
> > 1859 *result = *result;
>
> I think this is the expected behavior. Ignore this signal in debugger.
>
> > (dbx) print result
> > result = 0x402270 "<bad address 0x0000000000402270>"
>
> But the address looks too small for x64 target. Check GC_SysVGetDataStart parameters passed (compare to that in gctest).
>
> Regards.
>
> >
> > "os_dep.o" is compiled and linked to .libs/libgc.so.1.0.3: in make log:
> > libtool: compile: gcc -O2 -m64 -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -fexceptions -g -O2 -fno-strict-aliasing -MT os_dep.lo -MD -MP -MF .deps/os_dep.Tpo -c os_dep.c -fPIC -DPIC -o .libs/os_dep.o
> > ...
> > Do you have any suggestion ?
> >
> > Regards,
> >
> > --- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>
> >
More information about the Gc
mailing list