[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 23:11:10 PST 2012
Hi, Ivan,
Parameters of GC_SysVGetDataStart are:
guile:
(dbx) print max_page_size
max_page_size = 18446741324915316480U
(dbx) print etext_addr
etext_addr = 0xfffffd7fffdfe450 ""
gctest:
(dbx) print max_page_size
max_page_size = 4448192U
(dbx) print etext_addr
etext_addr = 0xfffffd7fffdfe530 ""
max_page_size in guile too large ?
Regards,
--- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>
--- On Sun, 2012/4/1, Ivan Maidanski <ivmai at mail.ru> wrote:
> Hi,
>
> Sun, 1 Apr 2012 15:43:21 +0900 (JST) от Kiyoshi KANAZAWA <yoi_no_myoujou at yahoo.co.jp>:
> > I haven't checked bdwgc "master" branch yet.
> > I'd like to do that after clearing in "release" branch.
>
> >> ... Check GC_SysVGetDataStart parameters passed (compare to that in gctest).
>
> > 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
>
> Code address is not needed to be compared I guess. Check params.
>
> Regards.
>
> >
> > 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>
> > > >
> >
> > _______________________________________________
> > Gc mailing list
> > Gc at linux.hpl.hp.com
> > http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> >
More information about the Gc
mailing list