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

[Ivan Maidanski]

Hi Kyioshi,

Sun, 1 Apr 2012 16:11:10 +0900 (JST) Kiyoshi KANAZAWA <yoi_no_myoujou at yahoo.co.jp>:
> 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 ?

Right. In both cases.

In gconfig.h, I can see only values in range 0x1000 ... 0x100000 for this parameter.

Regards.

> 
> 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/
> > > 
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>