[Bug java/23662] New: Binaries generated by arm-linux-gcj segfault on execution on arm target

[Bug java/23662] New: Binaries generated by arm-linux-gcj segfault on execution on arm target

[ngmlinux at gmail dot com]

A similar bug was reported against 3.1 (# 5487).  A new bug is being opened as
that bug had been misreported as fixed against 3.1 and has since been closed.

I've been able to reproduce the same exact issue in arm-linux-gcc-4.0.1 as
reported in Bug # 5487 against gcc-3.1 which I build from source by the
following process:
===code============================================================
../configure --target=arm-linux --with-gnu-as --with-gnu-ld
--enable-multilib --enable-languages=c,c++,java --disable-nls --nfp
--with-cpu-xscale --with-softfloat-support=internal
make
make install
===================================================================

I then compiled a HelloWorld.java App using the newly created gcj as follows:
===code============================================================
/usr/local/bin/arm-linux-gcj -static HelloWorld.java
--main=HelloWorldApp -g -o HelloWorld.exe
===================================================================

Compilation seemed to go fine without errors.  HelloWorld.exe appears to be a
correctly formated binary according to "file":
===code============================================================
HelloWorld.exe: ELF 32-bit LSB executable, Advanced RISC Machines ARM, version
1, statically linked, not stripped
===================================================================

The binary was then downloaded to a PXA-255 based system running armcore-2.6.7
linux.  Upon execution the executable reports the segmentation fault:
===code============================================================
[root@ARMCore test]$ ./HelloWorld.exe
Segmentation fault
===================================================================

-- 
           Summary: Binaries generated by arm-linux-gcj segfault on
                    execution on arm target
           Product: gcc
           Version: 4.0.1
            Status: UNCONFIRMED
          Severity: critical
          Priority: P2
         Component: java
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ngmlinux at gmail dot com
                CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
                    dot org
  GCC host triplet: x86, x86_64
GCC target triplet: arm


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug java/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[ngmlinux at gmail dot com]

------- Additional Comments From ngmlinux at gmail dot com  2005-08-31 21:00 -------
I now have a stacktrace from someone on this issue from gdb:
They used the following configuration parameters to build arm-linux-gcc cross
compilers:

The following was tested with gcc-3.4.3 and gcc-4.0.1 sources with the same results.
===code==================================================================
$ arm-linux-gcj -v
Configured with: ../gcc-3.4.3/configure --target=arm-linux
--prefix=/group/teaching/iar/armcore-gx/toolchain
--enable-languages=c,c++,objc,java --disable-nls --nfp --with-cpu=xscale
--with-softfloat-support=internal
Thread model: posix
gcc version 3.4.3
=========================================================================

Here is the stacktrace:

===code==================================================================
$ arm-linux-gcj -ggdb --main=HelloWorld -o hello HelloWorld.java
running ./hello causes segfault

$ gdb hello
Program received signal SIGSEGV, Segmentation fault.
GC_push_all_eager (bottom=0x0, top=0x390a8 "") at
../../../gcc-3.4.3/boehm-gc/mark.c:1468
1468    ../../../gcc-3.4.3/boehm-gc/mark.c: No such file or directory.
       in ../../../gcc-3.4.3/boehm-gc/mark.c

(gdb) bt
#0  GC_push_all_eager (bottom=0x0, top=0x390a8 "") at
../../../gcc-3.4.3/boehm-gc/mark.c:1468
#1  0x40637660 in GC_push_all_stacks () at
../../../gcc-3.4.3/boehm-gc/pthread_stop_world.c:232
#2  0x40632194 in GC_push_roots (all=1, cold_gc_frame=0xbefffaf4 "") at
../../../gcc-3.4.3/boehm-gc/mark_rts.c:643
#3  0x406316a4 in GC_mark_some (cold_gc_frame=0xbefffaf4 "") at
../../../gcc-3.4.3/boehm-gc/mark.c:326
#4  0x406289e8 in GC_stopped_mark (stop_func=0x40628640
<GC_never_stop_func>) at ../../../gcc-3.4.3/boehm-gc/alloc.c:517
#5  0x40629488 in GC_try_to_collect_inner (stop_func=0x40628640
<GC_never_stop_func>) at ../../../gcc-3.4.3/boehm-gc/alloc.c:364
#6  0x40632c38 in GC_init_inner () at ../../../gcc-3.4.3/boehm-gc/misc.c:758
#7  0x40632f00 in GC_init () at ../../../gcc-3.4.3/boehm-gc/misc.c:477
#8  0x4062d04c in GC_init_gcj_malloc (mp_index=0, mp=0x404337b8) at
../../../gcc-3.4.3/boehm-gc/gcj_mlc.c:60
#9  0x4043449c in _Jv_InitGC () at ../../../gcc-3.4.3/libjava/boehm.cc:526
#10 0x404367c4 in _Jv_CreateJavaVM () at
../../../gcc-3.4.3/libjava/prims.cc:907
#11 0x40436ca4 in _Jv_RunMain (klass=0x1107c, name=0x0, argc=1,
argv=0xbefffdb4, is_jar=false) at ../../../gcc-3.4.3/libjava/prims.cc:992
#12 0x40436ec4 in JvRunMain (klass=0x0, argc=-1090519712, argv=0x0) at
../../../gcc-3.4.3/libjava/prims.cc:1030
#13 0x00008b04 in main (argc=1, argv=0xbefffdb4) at /tmp/cccmH5zI.i:11
=========================================================================

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rearnsha at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-31 21:03 -------
>From your back trace this is in the GC and not really in an issue for the front-end or class library.

Also from the looks of it, you using gcj 4.0.0 but using 3.4.3's libgcj, this is not supported at all.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal
          Component|java                        |boehm-gc
 GCC target triplet|arm                         |arm-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-31 21:07 -------
The last known good test results from arm-linux:
http://gcc.gnu.org/ml/gcc-testresults/2003-06/msg00168.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-31 21:14 -------
Actually there is a later one:
http://gcc.gnu.org/ml/gcc-testresults/2004-04/msg00322.html

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[ngmlinux at gmail dot com]

------- Additional Comments From ngmlinux at gmail dot com  2005-09-01 00:57 -------
(In reply to comment #2)
> From your back trace this is in the GC and not really in an issue for the
front-end or class library.
> 
> Also from the looks of it, you using gcj 4.0.0 but using 3.4.3's libgcj, this
is not supported at all.

That is incorrect this bug has been verified with gcc-4.0.1 along with the 4.0.1
libgcj's as well as gcc-3.4.3 with the libgcj that comes with gcc-3.4.3.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[ngmlinux at gmail dot com]

------- Additional Comments From ngmlinux at gmail dot com  2005-09-01 01:02 -------
Is it neccissary for the host-to-host version of gcc to be the exact same
version as the host-to-target gcc version being built?  I doubt this is the case
as this would present major imcompatibility issues for many people.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[ngmlinux at gmail dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-01 01:08 -------
First don't add me to the CC, I read gcc-bugs.

(In reply to comment #6)
> Is it neccissary for the host-to-host version of gcc to be the exact same
> version as the host-to-target gcc version being built?  I doubt this is the case
> as this would present major imcompatibility issues for many people.

No. 

As I said this is a bug in boehm-gc, you might to see if you can use the latest version of  boehm-gc on 
your target. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|pinskia at gcc dot gnu dot  |
                   |org                         |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[ngmlinux at gmail dot com]

------- Additional Comments From ngmlinux at gmail dot com  2005-09-01 01:39 -------
(In reply to comment #7)
> First don't add me to the CC, I read gcc-bugs.
I appologize.
 
> As I said this is a bug in boehm-gc, you might to see if you can use the
latest version of  boehm-gc on 
> your target. 

Ok, I was not aware the target needed a boehm-gc utility.  I am unfamiliar with
why this would be needed and where on my target filesystem it should be placed.
 Is this something only required by java binaries?

On my host a "locate boehm-gc" pulls up basically two entries:
1. The following directory and it's contents:
/home/username/arm-linux-gcc-4.0.1/gcc-4.0.1/boehm-gc
2. The following header:
/home/username/arm-linux-gcc-4.0.1/gcc-4.0.1/libjava/include/boehm-gc.h

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[rmathew at gcc dot gnu dot org]

------- Additional Comments From rmathew at gcc dot gnu dot org  2005-09-01 09:36 -------
I think it is the same problem with Boehm-GC on ARM/Linux that
has been solved in upstream sources. See:

  http://www.hpl.hp.com/hosted/linux/mail-archives/gc/2005-July/000943.html
  http://www.hpl.hp.com/hosted/linux/mail-archives/gc/2005-August/000963.html

The relevant file can be found as $GCC_SRC_DIR/boehm-gc/include/private/gcconfig.h

You should rebuild GCC after making this change and try if it solves 
the problem for you.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[ngmlinux at gmail dot com]

------- Additional Comments From ngmlinux at gmail dot com  2005-09-01 19:46 -------
(In reply to comment #9)
> I think it is the same problem with Boehm-GC on ARM/Linux that
> has been solved in upstream sources.

Has this fix been officially submited to gcc for inclusion in 4.0.X?

Are any fixes required on the target itself (ie. in it's libraries) or just on
the arm-linux-gcj cross compiler source?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[rmathew at gcc dot gnu dot org]

------- Additional Comments From rmathew at gcc dot gnu dot org  2005-09-02 09:41 -------
(In reply to comment #10)
> (In reply to comment #9)
> > I think it is the same problem with Boehm-GC on ARM/Linux that
> > has been solved in upstream sources.
> 
> Has this fix been officially submited to gcc for inclusion in 4.0.X?

We import the Boehm-GC from time to time into mainline CVS (GCC) from 
upstream sources. I think upstream sources already have this patch applied.
It is unlikely that the 4.0.x series will pick up an updated Boehm-GC, 
though mainline can (although it is a bit too close to the 4.1 freeze).
In the interim, you can see if this resolves your issue and get by with
a local patch.


> Are any fixes required on the target itself (ie. in it's libraries) or just on
> the arm-linux-gcj cross compiler source?

Sorry, I don't know the answer to this as I work on x86-linux only. But from
perusing the related messages, it does not look like any other change is 
needed, but I might be mistaken.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[tromey at gcc dot gnu dot org]

------- Additional Comments From tromey at gcc dot gnu dot org  2005-09-02 17:15 -------
I don't think we'll import a new version of the GC into the 4.0.x series.
However, a patch to fix the ARM port would be perfectly fine.
If the patch works for you, please submit it to java-patches and I will
deal with it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[ngmlinux at gmail dot com]

------- Additional Comments From ngmlinux at gmail dot com  2005-09-04 00:14 -------
After patching the gcc-4.0.1 source in boehm-gc/include/private/gcconfig.h, I
get the following errors when I go to "make".  I did not get this errors before
editing gcconfig.h, however they appear to be unrelated:

===code============================================
In file included from ./gthr-default.h:1,
                from ../../gcc/gthr.h:114,
                from ../../gcc/unwind-dw2.c:42:
../../gcc/gthr-posix.h:43:21: error: pthread.h: No such file or directory
../../gcc/gthr-posix.h:44:20: error: unistd.h: No such file or directory
In file included from ./gthr-default.h:1,
                from ../../gcc/gthr.h:114,
                from ../../gcc/unwind-dw2.c:42:
../../gcc/gthr-posix.h:46: error: syntax error before '__gthread_key_t'
../../gcc/gthr-posix.h:46: warning: type defaults to 'int' in
declaration of '__gthread_key_t'
../../gcc/gthr-posix.h:46: warning: data definition has no type or
storage class../../gcc/gthr-posix.h:47: error: syntax error before
'__gthread_once_t'
../../gcc/gthr-posix.h:47: warning: type defaults to 'int' in
declaration of '__gthread_once_t'
../../gcc/gthr-posix.h:47: warning: data definition has no type or
storage class../../gcc/gthr-posix.h:48: error: syntax error before
'__gthread_mutex_t'
../../gcc/gthr-posix.h:48: warning: type defaults to 'int' in
declaration of '__gthread_mutex_t'
../../gcc/gthr-posix.h:48: warning: data definition has no type or
storage class../../gcc/gthr-posix.h:49: error: syntax error before
'__gthread_recursive_mutex_t'
../../gcc/gthr-posix.h:49: warning: type defaults to 'int' in
declaration of '__gthread_recursive_mutex_t'
../../gcc/gthr-posix.h:49: warning: data definition has no type or
storage class../../gcc/gthr-posix.h: In function '__gthread_active_p':
../../gcc/gthr-posix.h:110: error: 'pthread_cancel' undeclared (first
use in this function)
../../gcc/gthr-posix.h:110: error: (Each undeclared identifier is
reported only once
../../gcc/gthr-posix.h:110: error: for each function it appears in.)
../../gcc/gthr-posix.h: At top level:
../../gcc/gthr-posix.h:474: error: syntax error before '*' token
../../gcc/gthr-posix.h:474: error: syntax error before ')' token
../../gcc/gthr-posix.h:483: error: syntax error before '*' token
../../gcc/gthr-posix.h:483: error: syntax error before ')' token
../../gcc/gthr-posix.h:489: error: syntax error before 'key'
../../gcc/gthr-posix.h:490: warning: function declaration isn't a prototype
../../gcc/gthr-posix.h: In function '__gthread_key_delete':
../../gcc/gthr-posix.h:490: warning: old-style function definition
../../gcc/gthr-posix.h:491: warning: implicit declaration of function
'pthread_key_delete'
../../gcc/gthr-posix.h:491: error: 'key' undeclared (first use in this
function)../../gcc/gthr-posix.h: At top level:
../../gcc/gthr-posix.h:495: error: syntax error before 'key'
../../gcc/gthr-posix.h:496: warning: function declaration isn't a prototype
../../gcc/gthr-posix.h: In function '__gthread_getspecific':
../../gcc/gthr-posix.h:496: warning: old-style function definition
../../gcc/gthr-posix.h:497: warning: implicit declaration of function
'pthread_getspecific'
../../gcc/gthr-posix.h:497: error: 'key' undeclared (first use in this
function)../../gcc/gthr-posix.h:497: warning: return makes pointer
from integer without a cast
../../gcc/gthr-posix.h: At top level:
../../gcc/gthr-posix.h:501: error: syntax error before 'key'
../../gcc/gthr-posix.h:502: warning: function declaration isn't a prototype
../../gcc/gthr-posix.h: In function '__gthread_setspecific':
../../gcc/gthr-posix.h:502: warning: old-style function definition
../../gcc/gthr-posix.h:503: warning: implicit declaration of function
'pthread_setspecific'
../../gcc/gthr-posix.h:503: error: 'key' undeclared (first use in this
function)../../gcc/gthr-posix.h:503: error: 'ptr' undeclared (first
use in this function)../../gcc/gthr-posix.h: At top level:
../../gcc/gthr-posix.h:507: error: syntax error before '*' token
../../gcc/gthr-posix.h:508: warning: function declaration isn't a prototype
../../gcc/gthr-posix.h: In function '__gthread_mutex_lock':
../../gcc/gthr-posix.h:508: warning: old-style function definition
../../gcc/gthr-posix.h:510: warning: implicit declaration of function
'pthread_mutex_lock'
../../gcc/gthr-posix.h:510: error: 'mutex' undeclared (first use in
this function)
../../gcc/gthr-posix.h: At top level:
../../gcc/gthr-posix.h:516: error: syntax error before '*' token
../../gcc/gthr-posix.h:517: warning: function declaration isn't a prototype
../../gcc/gthr-posix.h: In function '__gthread_mutex_trylock':
../../gcc/gthr-posix.h:517: warning: old-style function definition
../../gcc/gthr-posix.h:519: warning: implicit declaration of function
'pthread_mutex_trylock'
../../gcc/gthr-posix.h:519: error: 'mutex' undeclared (first use in
this function)
../../gcc/gthr-posix.h: At top level:
../../gcc/gthr-posix.h:525: error: syntax error before '*' token
../../gcc/gthr-posix.h:526: warning: function declaration isn't a prototype
../../gcc/gthr-posix.h: In function '__gthread_mutex_unlock':
../../gcc/gthr-posix.h:526: warning: old-style function definition
../../gcc/gthr-posix.h:528: warning: implicit declaration of function
'pthread_mutex_unlock'
../../gcc/gthr-posix.h:528: error: 'mutex' undeclared (first use in
this function)
../../gcc/gthr-posix.h: At top level:
../../gcc/gthr-posix.h:535: error: syntax error before '*' token
../../gcc/gthr-posix.h:536: warning: function declaration isn't a prototype
../../gcc/gthr-posix.h: In function '__gthread_recursive_mutex_init_function':
../../gcc/gthr-posix.h:536: warning: old-style function definition
../../gcc/gthr-posix.h:539: error: 'pthread_mutexattr_t' undeclared
(first use in this function)
../../gcc/gthr-posix.h:539: error: syntax error before 'attr'
../../gcc/gthr-posix.h:542: warning: implicit declaration of function
'pthread_mutexattr_init'
../../gcc/gthr-posix.h:542: error: 'attr' undeclared (first use in
this function)
../../gcc/gthr-posix.h:544: warning: implicit declaration of function
'pthread_mutexattr_settype'
../../gcc/gthr-posix.h:544: error: 'PTHREAD_MUTEX_RECURSIVE'
undeclared (first use in this function)
../../gcc/gthr-posix.h:546: warning: implicit declaration of function
'pthread_mutex_init'
../../gcc/gthr-posix.h:546: error: 'mutex' undeclared (first use in
this function)
../../gcc/gthr-posix.h:548: warning: implicit declaration of function
'pthread_mutexattr_destroy'
../../gcc/gthr-posix.h: At top level:
../../gcc/gthr-posix.h:556: error: syntax error before '*' token
../../gcc/gthr-posix.h:557: warning: function declaration isn't a prototype
../../gcc/gthr-posix.h: In function '__gthread_recursive_mutex_lock':
../../gcc/gthr-posix.h:557: warning: old-style function definition
../../gcc/gthr-posix.h:558: error: 'mutex' undeclared (first use in
this function)
../../gcc/gthr-posix.h: At top level:
../../gcc/gthr-posix.h:562: error: syntax error before '*' token
../../gcc/gthr-posix.h:563: warning: function declaration isn't a prototype
../../gcc/gthr-posix.h: In function '__gthread_recursive_mutex_trylock':
../../gcc/gthr-posix.h:563: warning: old-style function definition
../../gcc/gthr-posix.h:564: error: 'mutex' undeclared (first use in
this function)
../../gcc/gthr-posix.h: At top level:
../../gcc/gthr-posix.h:568: error: syntax error before '*' token
../../gcc/gthr-posix.h:569: warning: function declaration isn't a prototype
../../gcc/gthr-posix.h: In function '__gthread_recursive_mutex_unlock':
../../gcc/gthr-posix.h:569: warning: old-style function definition
../../gcc/gthr-posix.h:570: error: 'mutex' undeclared (first use in
this function)
make[2]: *** [libgcc/./unwind-dw2.o] Error 1
make[2]: Leaving directory
`/home/username/arm-linux-gcc-4.0.1/gcc-4.0.1/arm-linux/gcc'
make[1]: *** [stmp-multilib] Error 2
make[1]: Leaving directory
`/home/username/arm-linux-gcc-4.0.1/gcc-4.0.1/arm-linux/gcc'
make: *** [all-gcc] Error 2
===================================================

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[ngmlinux at gmail dot com]

------- Additional Comments From ngmlinux at gmail dot com  2005-09-04 02:35 -------
Ok, tried the same fix on another test machine, this one running Mandriva 2005
LE x86_64 and the arm-linux-gcc-4.0.1 toolchain with the boehm-gc patch compiled
fine.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[ngmlinux at gmail dot com]

------- Additional Comments From ngmlinux at gmail dot com  2005-09-04 03:25 -------
Ok after recompiling the static HelloWorld.exe with the patched toolchain the
following happens upon execution on the target:

===code==========================================================================
[root@ARMCore test]$ ./HelloWorld.exe
HelloWorld.exe: dl-runtime.c:72: fixup: Assertion `((reloc->r_info) & 0xff) ==
22' failed.
Aborted
=================================================================================

The following post although refering to a dated toolchain appears as though it
may be relevant:
http://www.mail-archive.com/linux-arm@lists.arm.linux.org.uk/msg03071.html

Does this seem to be on the right track?

I'm noticing that in general, very few bugs if any in the arm-linux port of gcc
have been fixed since the gcc-2.x.x and gcc-3.x.x toolchain releases.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[ngmlinux at gmail dot com]

------- Additional Comments From ngmlinux at gmail dot com  2005-09-04 03:52 -------
Perhaps the above link does not apply, my host system doesn't contain a
"dl-machine.h" anywhere on the file system nor did a "glibc-current" directory
turn up.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[pinskia at physics dot uc dot edu]

------- Additional Comments From pinskia at physics dot uc dot edu  2005-09-04 04:07 -------
Subject: Re:  Binaries generated by arm-linux-gcj segfault on execution on arm target


On Sep 3, 2005, at 11:25 PM, ngmlinux at gmail dot com wrote:

>
> ------- Additional Comments From ngmlinux at gmail dot com  2005-09-04  
> 03:25 -------
> Ok after recompiling the static HelloWorld.exe with the patched  
> toolchain the
> following happens upon execution on the target:
>
> ===code================================================================ 
> ==========
> [root@ARMCore test]$ ./HelloWorld.exe
> HelloWorld.exe: dl-runtime.c:72: fixup: Assertion `((reloc->r_info) &  
> 0xff) ==
> 22' failed.
> Aborted
> ======================================================================= 
> ==========

This is a glibc bug in the dynamic loader.  Try a newer glibc.


-- Pinski



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[ngmlinux at gmail dot com]

------- Additional Comments From ngmlinux at gmail dot com  2005-09-04 04:20 -------
> This is a glibc bug in the dynamic loader.  Try a newer glibc.

Is this a glibc bug on the target or the host machine?  I believe my host would
have a very recent glibc, my target has an ancient glibc but I compiled my
HelloWorld.java as a staticly linked application thus I wouldn't expect it to
have any dependencies on the target.  ?



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-04 04:22 -------
(In reply to comment #18)
> Is this a glibc bug on the target or the host machine?  I believe my host would
> have a very recent glibc, my target has an ancient glibc but I compiled my
> HelloWorld.java as a staticly linked application thus I wouldn't expect it to
> have any dependencies on the target.  ?

You are running your program on the target right?  Then it is a bug on the target.  The dynamic loader 
still is invoked because well libjava still invokes it.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[ngmlinux at gmail dot com]

------- Additional Comments From ngmlinux at gmail dot com  2005-09-04 05:02 -------
> You are running your program on the target right?  Then it is a bug on the
target.  The dynamic loader 
> still is invoked because well libjava still invokes it.

I believe you as I still have glibc-2.2.2 on my target (I should have this
updated in a week or two).  Kind of defeats the whole point of static linking if
libraries are still needed on the target?  I assume only c libraries are need on
the target and not libjava, otherwise you minus well load a whole JVM and skip
gcj all together.

I'll provide an update on the issue once my c library has been updated (couple
weeks).

Thanks.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-09-06 14:21 -------
Subject: Bug 23662

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	tromey@gcc.gnu.org	2005-09-06 14:21:25

Modified files:
	boehm-gc       : ChangeLog 
	boehm-gc/include/private: gcconfig.h 

Log message:
	PR libgcj/23662:
	* include/private/gcconfig.h (LINUX_STACKBOTTOM): Use instead of
	HEURISTIC1 on ARM.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/boehm-gc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.219.2.7&r2=1.219.2.8
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/boehm-gc/include/private/gcconfig.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.39.18.4&r2=1.39.18.5



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-09-06 14:22 -------
Subject: Bug 23662

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	tromey@gcc.gnu.org	2005-09-06 14:22:01

Modified files:
	boehm-gc       : ChangeLog 
	boehm-gc/include/private: gcconfig.h 

Log message:
	PR libgcj/23662:
	* include/private/gcconfig.h (LINUX_STACKBOTTOM): Use instead of
	HEURISTIC1 on ARM.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/boehm-gc/ChangeLog.diff?cvsroot=gcc&r1=1.230&r2=1.231
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/boehm-gc/include/private/gcconfig.h.diff?cvsroot=gcc&r1=1.46&r2=1.47



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[tromey at gcc dot gnu dot org]

------- Additional Comments From tromey at gcc dot gnu dot org  2005-09-06 14:23 -------
Fix checked in to 4.0 branch and trunk.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED
            Version|4.0.1                       |4.0.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662

[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.0.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662