Problem with exceptions on arm

Problem with exceptions on arm

[Henrik Grindal Bakken]

Hi.  I have built myself a cross-compiler x86->arm-linuxeabi, with
which I'm having some problems.

My current toolchain is built like this:

    ../${GCCDIST}/configure \
        --build="${BUILD_ARCH}" \
        --host="${BUILD_ARCH}" \
        --target="${GNU_ARCH}" \
        --with-cross-host="${GNU_ARCH}" \
        --prefix="${PREFIX}" \
        --libdir="${PREFIX}/lib" \
        --includedir="${PREFIX}/include" \
        --with-headers="${PREFIX}/include" \
        --with-local-prefix="${PREFIX}/${GNU_ARCH}" \
        --program-prefix="${PROGRAM_PREFIX}" \
        --disable-nls \
        ${ARCHARG} ${FLOATARG} \
	${GMPARG} ${MPFRARG} \
        ${GCC_LANG_ARG} \
        ${GCC_CONF_ARG}
    make all && make install install_root="${PREFIX}"

BUILD_ARCH=i686-linux
GNU_ARCH=arm-linuxeabi
ARCH_ARG="--with-arch=armv5t --with-tune=arm926ej-s--with-cpu=arm926ej-s"
GCC_LANG_ARG="--enable-languages=c,c++"
GCC_CONF_ARG="\
        --enable-shared \
        --enable-threads=posix \
        --enable-symvers=gnu \
        "

This is part of a larger script setting up a cross-compiling
toolchain.  binutils, glibc and a first-stage gcc for arm is already
built at this point.  I have tried gcc-4.2.2 and gcc-4.2.3.  Our
codebase isn't quite ready for 4.3 yet...

When I run on target, a simple test program with exceptions fail:
===8<===8<===
#include <stdio.h>
#include <stdlib.h>

int main() {
   try {
       throw "hello";
   }
   catch(const char *e) {
       fprintf(stderr, "I caught %s\n", e);
       exit(1);
   }
   catch(...) {
       fprintf(stderr, "I caught something\n");
       exit(1);
   }
   fprintf(stderr, "Still happy, but why??\n");
   exit(0);
}
===8<===8<===

Fails like this:
$ /tmp/fnord 
terminate called after throwing an instance of 'char*'
terminate called recursively
Aborted

I've also tried throwing ints, but to no avail.

The test application was built like this:
arm-linuxeabi-g++ -fexceptions -frtti -o /tmp/fnord /tmp/fnord.cpp

My next try is a new toolchain, built with --with-sjlj-exceptions, but
then gcc fails to build:

/home/hgb/src/dev/toolchain/arm_gcc-4.2.3_glibc-2.7_i686-linux-1/build-gcc-full/./gcc/xgcc -shared-libgcc -B/home/hgb/src/dev/toolchain/arm_gcc-4.2.3_glibc-2.7_i686-linux-1/build-gcc-full/./gcc -nostdinc++ -L/home/hgb/src/dev/toolchain/arm_gcc-4.2.3_glibc-2.7_i686-linux-1/build-gcc-full/arm-linuxeabi/libstdc++-v3/src -L/home/hgb/src/dev/toolchain/arm_gcc-4.2.3_glibc-2.7_i686-linux-1/build-gcc-full/arm-linuxeabi/libstdc++-v3/src/.libs -B/home/hgb/src/dev/toolchain/arm_gcc-4.2.3_glibc-2.7_i686-linux-1/arm_gcc-4.2.3_glibc-2.7_i686-linux-1/arm-linuxeabi/bin/ -B/home/hgb/src/dev/toolchain/arm_gcc-4.2.3_glibc-2.7_i686-linux-1/arm_gcc-4.2.3_glibc-2.7_i686-linux-1/arm-linuxeabi/lib/ -isystem /home/hgb/src/dev/toolchain/arm_gcc-4.2.3_glibc-2.7_i686-linux-1/arm_gcc-4.2.3_glibc-2.7_i686-linux-1/arm-linuxeabi/include -isystem /home/hgb/src/dev/toolchain/arm_gcc-4.2.3_glibc-2.7_i686-linux-1/arm_gcc-4.2.3_glibc-2.7_i686-linux-1/arm-linuxeabi/sys-include -I/home/hgb/src/dev/toolchain/arm_gcc-4.2.3_glibc-2.7_i686-linux-1/gcc-4.2.3/libstdc++-v3/../gcc -I/home/hgb/src/dev/toolchain/arm_gcc-4.2.3_glibc-2.7_i686-linux-1/build-gcc-full/arm-linuxeabi/libstdc++-v3/include/arm-linuxeabi -I/home/hgb/src/dev/toolchain/arm_gcc-4.2.3_glibc-2.7_i686-linux-1/build-gcc-full/arm-linuxeabi/libstdc++-v3/include -I/home/hgb/src/dev/toolchain/arm_gcc-4.2.3_glibc-2.7_i686-linux-1/gcc-4.2.3/libstdc++-v3/libsupc++ -I/home/hgb/src/dev/toolchain/arm_gcc-4.2.3_glibc-2.7_i686-linux-1/arm_gcc-4.2.3_glibc-2.7_i686-linux-1/include -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -c ../../../../gcc-4.2.3/libstdc++-v3/libsupc++/eh_alloc.cc  -fPIC -DPIC -o eh_alloc.o
/tmp/ccc0srso.s: Assembler messages:
/tmp/ccc0srso.s:649: Error: duplicate .personality directive
/tmp/ccc0srso.s:1200: Error: duplicate .personality directive
make[4]: *** [eh_alloc.lo] Error 1
make[4]: Leaving directory `/home/hgb/src/dev/toolchain/arm_gcc-4.2.3_glibc-2.7_i686-linux-1/build-gcc-full/arm-linuxeabi/libstdc++-v3/libsupc++'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/hgb/src/dev/toolchain/arm_gcc-4.2.3_glibc-2.7_i686-linux-1/build-gcc-full/arm-linuxeabi/libstdc++-v3'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/hgb/src/dev/toolchain/arm_gcc-4.2.3_glibc-2.7_i686-linux-1/build-gcc-full/arm-linuxeabi/libstdc++-v3'
make[1]: *** [all-target-libstdc++-v3] Error 2
make[1]: Leaving directory `/home/hgb/src/dev/toolchain/arm_gcc-4.2.3_glibc-2.7_i686-linux-1/build-gcc-full'

Does anyone have any great ideas as to either how to get exceptions
working without --with-sjlj-exceptions, or alternatively how to get
that working?

-- 
Henrik Grindal Bakken <hgb@ifi.uio.no>
PGP ID: 8D436E52
Fingerprint: 131D 9590 F0CF 47EF 7963  02AF 9236 D25A 8D43 6E52

Re: Problem with exceptions on arm

[Martin Guy]

On 3/27/08, Henrik Grindal Bakken <hgb@ifi.uio.no> wrote:
>
>  Hi.  I have built myself a cross-compiler x86->arm-linuxeabi, with
>  which I'm having some problems.
>  When I run on target, a simple test program with exceptions fail:
>  $ /tmp/fnord
>  terminate called after throwing an instance of 'char*'
>  terminate called recursively
>  Aborted

Hi Henrik
  I just tried your test program on Debian "armel"'s native gnueabi
g++ (4.2.3), and it catches "hello" fine. Their gcc -v says:

Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
--disable-libmudflap --disable-libssp --disable-sjlj-exceptions
--enable-checking=release --build=arm-linux-gnueabi
--host=arm-linux-gnueabi --target=arm-linux-gnueabi
Thread model: posix
gcc version 4.2.3 (Debian 4.2.3-2)

In case that's any help

    M

Re: Problem with exceptions on arm

[Henrik Grindal Bakken]

"Martin Guy" <martinwguy@yahoo.it> writes:

> On 3/27/08, Henrik Grindal Bakken <hgb@ifi.uio.no> wrote:
>>
>>  Hi.  I have built myself a cross-compiler x86->arm-linuxeabi, with
>>  which I'm having some problems.
>>  When I run on target, a simple test program with exceptions fail:
>>  $ /tmp/fnord
>>  terminate called after throwing an instance of 'char*'
>>  terminate called recursively
>>  Aborted
>
> Hi Henrik
>   I just tried your test program on Debian "armel"'s native gnueabi
> g++ (4.2.3), and it catches "hello" fine. Their gcc -v says:
>
> Using built-in specs.
> Target: arm-linux-gnueabi
> Configured with: ../src/configure -v
> --enable-languages=c,c++,fortran,obj-c++,treelang --prefix=/usr
> --enable-shared --with-system-zlib --libexecdir=/usr/lib
> --without-included-gettext --enable-threads=posix --enable-nls
> --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
> --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
> --disable-libmudflap --disable-libssp --disable-sjlj-exceptions
> --enable-checking=release --build=arm-linux-gnueabi
> --host=arm-linux-gnueabi --target=arm-linux-gnueabi
> Thread model: posix
> gcc version 4.2.3 (Debian 4.2.3-2)
>
> In case that's any help

Thanks, Martin.  It does help a little, I guess (ruling out
sjlj-exceptions, for one), but nothing springs at me from that
configure line.  Could this be kernel related?

-- 
Henrik Grindal Bakken <hgb@ifi.uio.no>
PGP ID: 8D436E52
Fingerprint: 131D 9590 F0CF 47EF 7963  02AF 9236 D25A 8D43 6E52

Re: Problem with exceptions on arm

[Andrew Haley]

Henrik Grindal Bakken wrote:
> "Martin Guy" <martinwguy@yahoo.it> writes:
> 
>> On 3/27/08, Henrik Grindal Bakken <hgb@ifi.uio.no> wrote:
>>>  Hi.  I have built myself a cross-compiler x86->arm-linuxeabi, with
>>>  which I'm having some problems.
>>>  When I run on target, a simple test program with exceptions fail:
>>>  $ /tmp/fnord
>>>  terminate called after throwing an instance of 'char*'
>>>  terminate called recursively
>>>  Aborted
>> Hi Henrik
>>   I just tried your test program on Debian "armel"'s native gnueabi
>> g++ (4.2.3), and it catches "hello" fine. Their gcc -v says:
>>
>> Using built-in specs.
>> Target: arm-linux-gnueabi
>> Configured with: ../src/configure -v
>> --enable-languages=c,c++,fortran,obj-c++,treelang --prefix=/usr
>> --enable-shared --with-system-zlib --libexecdir=/usr/lib
>> --without-included-gettext --enable-threads=posix --enable-nls
>> --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
>> --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
>> --disable-libmudflap --disable-libssp --disable-sjlj-exceptions
>> --enable-checking=release --build=arm-linux-gnueabi
>> --host=arm-linux-gnueabi --target=arm-linux-gnueabi
>> Thread model: posix
>> gcc version 4.2.3 (Debian 4.2.3-2)
>>
>> In case that's any help
> 
> Thanks, Martin.  It does help a little, I guess (ruling out
> sjlj-exceptions, for one), but nothing springs at me from that
> configure line.  Could this be kernel related?

Yes, but it's much more likely to be libc releated.

Andrew.

Re: Problem with exceptions on arm

[Henrik Grindal Bakken]

Andrew Haley <aph@redhat.com> writes:

> Henrik Grindal Bakken wrote:
>> Thanks, Martin.  It does help a little, I guess (ruling out
>> sjlj-exceptions, for one), but nothing springs at me from that
>> configure line.  Could this be kernel related?
>
> Yes, but it's much more likely to be libc releated.

Any usual suspects there?  I'm pretty certain the libc on target and
host (i.e. in the toolchain) are identical save for debug info.  When
stripped, they compute to the same sha1 checksum.

I build glibc like this:

            BUILD_CC=gcc \
                AS=${PROGRAM_PREFIX}as \
                CC=${PROGRAM_PREFIX}gcc \
                AR=${PROGRAM_PREFIX}ar \
                LD=${PROGRAM_PREFIX}ld \
                RANLIB=${PROGRAM_PREFIX}ranlib \
                CFLAGS="${GLIBC_CFLAGS}" \
                ../${GLIBCDIST}/configure \
                --host=${GNU_ARCH} \
                --build=${BUILD_ARCH} \
                --prefix=/ \
                --enable-add-ons=$THREADADDON \
                --with-headers=${PREFIX}/${GNU_ARCH}/sys-include \
                --without-cvs \
                --disable-debug \
                --disable-profile \
                --without-gd \
                --without-selinux \
                --enable-static \
                --enable-shared \
                --cache-file=config.cache \
                $GLIBC_CONF_FLAGS

Where GLIBC_CONF_FLAGS="--with-__thread --with-tls -without-fp"
(Hmm.  I actually use -without, not --without, but perhaps configure
doesn't separate...)

Also, I set
                echo "libc_cv_forced_unwind=$UNWIND" > config.cache
                echo "libc_cv_c_cleanup=yes" >> config.cache

THREADADDON is nptl.


-- 
Henrik Grindal Bakken <hgb@ifi.uio.no>
PGP ID: 8D436E52
Fingerprint: 131D 9590 F0CF 47EF 7963  02AF 9236 D25A 8D43 6E52

Re: Problem with exceptions on arm

[Martin Guy]

On 3/31/08, Henrik Grindal Bakken <hgb@ifi.uio.no> wrote:
>  Also, I set
>                 echo "libc_cv_forced_unwind=$UNWIND" > config.cache
>                 echo "libc_cv_c_cleanup=yes" >> config.cache

And what is $UNWIND? I assume you do this before "configure"?

   M

Re: Problem with exceptions on arm

[Henrik Grindal Bakken]

"Martin Guy" <martinwguy@yahoo.it> writes:

> On 3/31/08, Henrik Grindal Bakken <hgb@ifi.uio.no> wrote:
>>  Also, I set
>>                 echo "libc_cv_forced_unwind=$UNWIND" > config.cache
>>                 echo "libc_cv_c_cleanup=yes" >> config.cache
>
> And what is $UNWIND? I assume you do this before "configure"?

Ah, doh.  It's 'yes'.  And it's done before configure.


-- 
Henrik Grindal Bakken <hgb@ifi.uio.no>
PGP ID: 8D436E52
Fingerprint: 131D 9590 F0CF 47EF 7963  02AF 9236 D25A 8D43 6E52

Re: Problem with exceptions on arm

[Henrik Grindal Bakken]

Henrik Grindal Bakken <hgb@ifi.uio.no> writes:

> Fails like this:
> $ /tmp/fnord 
> terminate called after throwing an instance of 'char*'
> terminate called recursively
> Aborted

An update on this one.  I have now built on another host (thanks,
Martin!), and with my own toolchain, and static linking succeeds,
dynamic linking fails.  I suppose the only conclusion to draw from
this is that there are problems with my dynamic libraries.  I don't
know which libraries are relevant here, but I'd guess at least libc
and libstdc++.  I'll investigate some more.

-- 
Henrik Grindal Bakken <hgb@ifi.uio.no>
PGP ID: 8D436E52
Fingerprint: 131D 9590 F0CF 47EF 7963  02AF 9236 D25A 8D43 6E52

Re: Problem with exceptions on arm

[Martin Guy]

On 4/1/08, Henrik Grindal Bakken <hgb@ifi.uio.no> wrote:
> Henrik Grindal Bakken <hgb@ifi.uio.no> writes:
>
>  > Fails like this:
>  > $ /tmp/fnord
>  > terminate called after throwing an instance of 'char*'
>  > terminate called recursively
>  > Aborted

>  dynamic linking fails.

martin@n2100:~$ g++ fnord.cpp
martin@n2100:~$ ./a.out
I caught hello
martin@n2100:~$ file a.out
a.out: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux
2.6.14, dynamically linked (uses shared libs), not stripped

Do you mean when you import your cross-compiled .o's to it and link then there?

   M

Re: Problem with exceptions on arm

[Andrew Haley]

Martin Guy wrote:
> On 4/1/08, Henrik Grindal Bakken <hgb@ifi.uio.no> wrote:
>> Henrik Grindal Bakken <hgb@ifi.uio.no> writes:
>>
>>  > Fails like this:
>>  > $ /tmp/fnord
>>  > terminate called after throwing an instance of 'char*'
>>  > terminate called recursively
>>  > Aborted
> 
>>  dynamic linking fails.
> 
> martin@n2100:~$ g++ fnord.cpp
> martin@n2100:~$ ./a.out
> I caught hello
> martin@n2100:~$ file a.out
> a.out: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux
> 2.6.14, dynamically linked (uses shared libs), not stripped
> 
> Do you mean when you import your cross-compiled .o's to it and link then there?

Is there something weird going on here, like different libraries
in x-host and target?

Andrew.

Re: Problem with exceptions on arm

[Henrik Grindal Bakken]

"Martin Guy" <martinwguy@yahoo.it> writes:

> On 4/1/08, Henrik Grindal Bakken <hgb@ifi.uio.no> wrote:
>> Henrik Grindal Bakken <hgb@ifi.uio.no> writes:
>>
>>  > Fails like this:
>>  > $ /tmp/fnord
>>  > terminate called after throwing an instance of 'char*'
>>  > terminate called recursively
>>  > Aborted
>
>>  dynamic linking fails.
>
> martin@n2100:~$ g++ fnord.cpp
> martin@n2100:~$ ./a.out
> I caught hello
> martin@n2100:~$ file a.out
> a.out: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux
> 2.6.14, dynamically linked (uses shared libs), not stripped
>
> Do you mean when you import your cross-compiled .o's to it and link
> then there?

Ah, no.  I meant that if I do (on your box):
$ g++ -o fnord fnord.cpp
and run it on my box, it fails.  It works on your box.

If I do
$ g++ -static -o fnord.static fnord.cpp
and run it, it works.  And it doesn't seem to matter if I use your or
mine toolchain.

My libraries on target are stripped, but it doesn't appear to make a
difference if I use the non-stripped version.

It appears that either I make a mistake on transfer of .so files to
target, or my toolchain is built with inferior shared libraries (but
working static libraries).


-- 
Henrik Grindal Bakken <hgb@ifi.uio.no>
PGP ID: 8D436E52
Fingerprint: 131D 9590 F0CF 47EF 7963  02AF 9236 D25A 8D43 6E52

Re: Problem with exceptions on arm

[Kai Ruottu]

Andrew Haley wrote:

> Is there something weird going on here, like different libraries
> in x-host and target?

Nice to see someone else suspecting weirdness in the current ideas.
The first message in this thread told :

  "This is part of a larger script setting up a cross-compiling
  toolchain.  binutils, glibc and a first-stage gcc for arm is already
  built at this point.  I have tried gcc-4.2.2 and gcc-4.2.3.  Our
  codebase isn't quite ready for 4.3 yet...

  When I run on target, a simple test program with exceptions fail:"

The weird thing here is that installing the produced glibc runtime
onto the target isn't mentioned. People produce glibc when the target
yet hasn't it, if it has it then there is no reason to try to create
that "byte-by-byte identical" target C library...

Re: Problem with exceptions on arm

[Henrik Grindal Bakken]

Andrew Haley <aph@redhat.com> writes:

> Is there something weird going on here, like different libraries in
> x-host and target?

I don't think there should be.  I've tried copying in libgcc_s.so.1,
libc-2.7.so, libm-2.7.so and libstdc++.so.6.0.9 from the toolchain,
and the same thing happens.  I was hoping not stripping them would
help, but it didn't.


-- 
Henrik Grindal Bakken <hgb@ifi.uio.no>
PGP ID: 8D436E52
Fingerprint: 131D 9590 F0CF 47EF 7963  02AF 9236 D25A 8D43 6E52

Re: Problem with exceptions on arm

[Henrik Grindal Bakken]

Kai Ruottu <kai.ruottu@wippies.com> writes:

> Andrew Haley wrote:
>
>> Is there something weird going on here, like different libraries
>> in x-host and target?
>
> Nice to see someone else suspecting weirdness in the current
> ideas. The first message in this thread told :
>
>  "This is part of a larger script setting up a cross-compiling
>  toolchain.  binutils, glibc and a first-stage gcc for arm is
>  already built at this point.  I have tried gcc-4.2.2 and gcc-4.2.3.
>  Our codebase isn't quite ready for 4.3 yet...
>
>  When I run on target, a simple test program with exceptions fail:"
>
> The weird thing here is that installing the produced glibc runtime
> onto the target isn't mentioned. People produce glibc when the
> target yet hasn't it, if it has it then there is no reason to try to
> create that "byte-by-byte identical" target C library...

That was certainly a piece of info missing from my emails.  The
libraries from the cross-compiling toolchains are copied to target.
All .so files and relevant symlinks (perhaps skipping a few we don't
need) are copied from the "lib" subdirectory in the toolchain.  They
are, however, first stripped (just running arm-linuxeabi-strip, not
with -g), but I see the same behaviour when I skip this step.

As far as I can see, the .so files on target /lib match the ones from
lib in my toolchain.


-- 
Henrik Grindal Bakken <hgb@ifi.uio.no>
PGP ID: 8D436E52
Fingerprint: 131D 9590 F0CF 47EF 7963  02AF 9236 D25A 8D43 6E52

Re: Problem with exceptions on arm

[Henrik Grindal Bakken]

Andrew Haley <aph@redhat.com> writes:

> Is there something weird going on here, like different libraries in
> x-host and target?

When I copy libstdc++.so from the debian install, it works.
Apparently, my libstdc++.so is broken, somehow.  This requires some
investigation.


-- 
Henrik Grindal Bakken <hgb@ifi.uio.no>
PGP ID: 8D436E52
Fingerprint: 131D 9590 F0CF 47EF 7963  02AF 9236 D25A 8D43 6E52

Re: Problem with exceptions on arm

[Andrew Haley]

Kai Ruottu wrote:
> Andrew Haley wrote:
> 
>> Is there something weird going on here, like different libraries
>> in x-host and target?
> 
> Nice to see someone else suspecting weirdness in the current ideas.
> The first message in this thread told :
> 
>  "This is part of a larger script setting up a cross-compiling
>  toolchain.  binutils, glibc and a first-stage gcc for arm is already
>  built at this point.  I have tried gcc-4.2.2 and gcc-4.2.3.  Our
>  codebase isn't quite ready for 4.3 yet...
> 
>  When I run on target, a simple test program with exceptions fail:"
> 
> The weird thing here is that installing the produced glibc runtime
> onto the target isn't mentioned.

There must be some glibc runtime on the target, or dynamic linking
wouldn't have been tried.

Andrew.