freebsd gcc cross compiler creates binaries that crash when using c++ exceptions

freebsd gcc cross compiler creates binaries that crash when using c++ exceptions

[Markus Henschel]

Hello,

I have set up a cross compile toolchain that targets freebsd and runs on my linux host that doesn't work correctly. This is what I did:


0. Prerequisites
I want the toolchain to reside in /home/ubuntu/crossroot. So I copied these files from a FreeBSD 7.1 installation to this directory:
/usr/include/...
/usr/lib/...
/lib/...


1. create binutils in (2.21)
../../src/binutils/configure --target=i386-pc-freebsd7.1 --disable-nls --prefix=/home/ubuntu/crossroot --with-sysroot=/home/ubuntu/crossroot
make 
make install

2. create gcc (4.2.4)
../..src/gcc/configure --target=i386-pc-freebsd7.1 --disable-nls --prefix=/home/ubuntu/crossroot --with-sysroot=/home/ubuntu/crossroot --enable-languages=c,c++
make
make install

There are no errors in this process. But when I try to compile a simple test program using c++ exceptions and run it on the target machine I get a segmentation fault after the exception is catched. I statically linked libstdc++ and libgcc. The dynamically linked version seems to run but only because libgcc.so and libstdc++.so from the target machine are picked. If I copy over the versions from the created toolchain I get the same crashes again. If no exceptions are thrown everything works as it should.

To figure out what I did wrong I tried this:

A) Use the same sources for gcc and binutils and build a cross toolchain for linux (a different linux). This toolchain works as it should.
B) Build the same toolchain natively on the FreeBSD system I got the dependencies from. This toolchain works too.

So I took all compiler support libraries (like libstdc++.*, libgcc.*, ...) from the working native freebsd build of the toolchain and copied them over to the cross toolchain for freebsd. This seemed to cure the problem. So I guess something must have went wrong when building libgcc. 

Is there some flaw in the way I built this toolchain? Where could I try to start looking for the source of the problem? I can add all sorts of other outputs from the created toolchains if it helps.

Thank you

Markus

P.S.: This list is really awesome. I had multiple questions in the last days and they all have been answered quickly.

Re: freebsd gcc cross compiler creates binaries that crash when using c++ exceptions

[Andrew Haley]

On 01/12/2012 06:55 PM, Markus Henschel wrote:
> Is there some flaw in the way I built this toolchain? Where could I try to start looking for the source of the problem? I can add all sorts of other outputs from the created toolchains if it helps.

I wouldn't put the installed compiler (i.e. the prefix=) into the
same directory as the sysroot.  The sysroot should be a clean &
pristine copy of the root directories on your target.  It isn't
written to, only read from.  Once you have done your make install
you should have a set of target libraries that work in your
prefix/lib.

You can't mix the c++ and libgcc libraries you just built with the
versions on your target system.  It should be possible to install
the newly-created ones side by side with the versions on your target
system.

If that still doesn't work, time to start gdb.

Andrew.

RE: freebsd gcc cross compiler creates binaries that crash when using c++ exceptions

[Markus Henschel]

> On 01/12/2012 06:55 PM, Markus Henschel wrote:
> > Is there some flaw in the way I built this toolchain? Where could I
> try to start looking for the source of the problem? I can add all sorts
> of other outputs from the created toolchains if it helps.
> 
> I wouldn't put the installed compiler (i.e. the prefix=) into the same
> directory as the sysroot.  The sysroot should be a clean & pristine
> copy of the root directories on your target.  It isn't written to, only
> read from.  Once you have done your make install you should have a set
> of target libraries that work in your prefix/lib.

I did this because I had problems building a relocatable toolchain. When "prefix" was different from "sysroot" the compiler used an absolute path to some files in sysroot. But I can change that to see if it helps.

> 
> You can't mix the c++ and libgcc libraries you just built with the
> versions on your target system.  It should be possible to install the
> newly-created ones side by side with the versions on your target
> system.

May be I should explain better:
Usually I link libgcc and libstdc++ statically to not interfere with whatever is installed on the target system. Because I got these crashes I started playing around. I linked my test app dynamically against libgcc.so and libstdc++.so. Then I copied my test app to the target system and used the installed versions of these libraries. This seems to work. I just did this by accident. This brought me to my conclusion that something must be wrong with these libs that I created while building the cross compiler. I should also mention that the versions of the compiler support libraries on the target system come from gcc 4.2.1 so they are "similar enough" to what my binaries needed.

So I started to build my toolchain on the target system as a native compiler with exactly the same configure switches. This also produced working versions of libgcc and libstdc++.

Re: freebsd gcc cross compiler creates binaries that crash when using c++ exceptions

[Andrew Haley]

On 01/12/2012 07:25 PM, Markus Henschel wrote:
>> On 01/12/2012 06:55 PM, Markus Henschel wrote:
>>> Is there some flaw in the way I built this toolchain? Where could I
>> try to start looking for the source of the problem? I can add all sorts
>> of other outputs from the created toolchains if it helps.
>>
>> I wouldn't put the installed compiler (i.e. the prefix=) into the same
>> directory as the sysroot.  The sysroot should be a clean & pristine
>> copy of the root directories on your target.  It isn't written to, only
>> read from.  Once you have done your make install you should have a set
>> of target libraries that work in your prefix/lib.
> 
> I did this because I had problems building a relocatable
> toolchain. When "prefix" was different from "sysroot" the compiler
> used an absolute path to some files in sysroot.

Well, surely that's exactly what you want, otherwise how could it ever
find sysroot?

>> You can't mix the c++ and libgcc libraries you just built with the
>> versions on your target system.  It should be possible to install the
>> newly-created ones side by side with the versions on your target
>> system.
> 
> May be I should explain better:

> Usually I link libgcc and libstdc++ statically to not interfere with
> whatever is installed on the target system.

This is a bad idea: statically-linked libgcc doesn't play well with
any shared libraries.

> Because I got these crashes I started playing around. I linked my
> test app dynamically against libgcc.so and libstdc++.so. Then I
> copied my test app to the target system and used the installed
> versions of these libraries. This seems to work. I just did this by
> accident. This brought me to my conclusion that something must be
> wrong with these libs that I created while building the cross
> compiler.

Perhaps so.

> I should also mention that the versions of the compiler support
> libraries on the target system come from gcc 4.2.1 so they are
> "similar enough" to what my binaries needed.
> 
> So I started to build my toolchain on the target system as a native
> compiler with exactly the same configure switches. This also
> produced working versions of libgcc and libstdc++.

As you'd expect.

Like I said, you've got to break out the debugger to find out what is
wrong.

Andrew.

RE: freebsd gcc cross compiler creates binaries that crash when using c++ exceptions

[Markus Henschel]

> On 01/12/2012 07:25 PM, Markus Henschel wrote:
> >> On 01/12/2012 06:55 PM, Markus Henschel wrote:
> >>> Is there some flaw in the way I built this toolchain? Where could I
> >> try to start looking for the source of the problem? I can add all
> >> sorts of other outputs from the created toolchains if it helps.
> >>
> >> I wouldn't put the installed compiler (i.e. the prefix=) into the
> >> same directory as the sysroot.  The sysroot should be a clean &
> >> pristine copy of the root directories on your target.  It isn't
> >> written to, only read from.  Once you have done your make install
> you
> >> should have a set of target libraries that work in your prefix/lib.
> >
> > I did this because I had problems building a relocatable toolchain.
> > When "prefix" was different from "sysroot" the compiler used an
> > absolute path to some files in sysroot.
> 
> Well, surely that's exactly what you want, otherwise how could it ever
> find sysroot?
> >> You can't mix the c++ and libgcc libraries you just built with the
> >> versions on your target system.  It should be possible to install
> the
> >> newly-created ones side by side with the versions on your target
> >> system.
> >
> > May be I should explain better:
> 
> > Usually I link libgcc and libstdc++ statically to not interfere with
> > whatever is installed on the target system.
> 
> This is a bad idea: statically-linked libgcc doesn't play well with any
> shared libraries.

In our case this is desired. We do not link any C++ libraries because the target systems OS (which is not under our control) is ancient as well as the default system compilers. So all we use is libc and some other libraries with C-API to be able to upgrade our compilers and dependencies as we like. But as far as I can see it isn't part of the problem. The simple test case only linked to libgcc and libstdc++ (and libc,libm).

> > Because I got these crashes I started playing around. I linked my
> test
> > app dynamically against libgcc.so and libstdc++.so. Then I copied my
> > test app to the target system and used the installed versions of
> these
> > libraries. This seems to work. I just did this by accident. This
> > brought me to my conclusion that something must be wrong with these
> > libs that I created while building the cross compiler.
> 
> Perhaps so.
> 
> > I should also mention that the versions of the compiler support
> > libraries on the target system come from gcc 4.2.1 so they are
> > "similar enough" to what my binaries needed.
> >
> > So I started to build my toolchain on the target system as a native
> > compiler with exactly the same configure switches. This also produced
> > working versions of libgcc and libstdc++.
> 
> As you'd expect.
> 
> Like I said, you've got to break out the debugger to find out what is
> wrong.
> 
> Andrew.

What I did so far was attaching gdb and seeing that it crashes in libgcc in __cxa_end_catch. I guess I'll have to build libgcc with debug symbols then.

Thanks for the tips so far. Any further input is welcome.

Markus.

Re: freebsd gcc cross compiler creates binaries that crash when using c++ exceptions

[Andrew Haley]

On 01/16/2012 09:30 AM, Markus Henschel wrote:
> What I did so far was attaching gdb and seeing that it crashes in libgcc in __cxa_end_catch. I guess I'll have to build libgcc with debug symbols then.

This is almost always a mismatch of libraries: there is a complex
set of interdependencies between libc, libstdc++, and libgcc.

Andrew.

Re: freebsd gcc cross compiler creates binaries that crash when using c++ exceptions

[Andrew Haley]

On 01/16/2012 10:44 AM, Andrew Haley wrote:
> On 01/16/2012 09:30 AM, Markus Henschel wrote:
>> What I did so far was attaching gdb and seeing that it crashes in libgcc in __cxa_end_catch. I guess I'll have to build libgcc with debug symbols then.
> 
> This is almost always a mismatch of libraries: there is a complex
> set of interdependencies between libc, libstdc++, and libgcc.

By the way, what does a native freebsd gcc do?

Andrew

Re: freebsd gcc cross compiler creates binaries that crash when using c++ exceptions

[Kai Ruottu]

16.1.2012 11:30, Markus Henschel kirjoitti:

>>> So I started to build my toolchain on the target system as a native
>>> compiler with exactly the same configure switches. This also produced
>>> working versions of libgcc and libstdc++.
>
> What I did so far was attaching gdb and seeing that it crashes in libgcc
 > in __cxa_end_catch. I guess I'll have to build libgcc with debug symbols
 > then.

There has always been and most probably still is a difference between
library configures in a native and a cross build. The library configures
may do some run tests with simple apps. The native target system of
course can run the test programs the new GCC has compiled and linked
against the target startups and the standard C library. But the cross
host as default cannot run anything made for the target system, so the
configure scripts must know or guess (right) the features the target
system has!

So generally the libgcc and libstdc++ configures should know the
features all the "supported" systems have and produce identical
results in both native and cross complile cases. Never any "run
on target" tests done in order to find out how the target system
will behave! I don't think this already being the case with not
so common targets like FreeBSD but probably Linux is so well-known
and in embedded Linux target cases the shared libgcc and libstdc++
will more often be produced via crosscompiling than natively. NetBSD
and OpenBSD may also be embedded targets but FreeBSD, Solaris2 (and
other Unices) only system targets for which the native compile is
the most common...

RE: freebsd gcc cross compiler creates binaries that crash when using c++ exceptions

[Markus Henschel]

> -----Original Message-----
> From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
> Behalf Of Andrew Haley
> Sent: Montag, 16. Januar 2012 11:47
> To: gcc-help@gcc.gnu.org
> Subject: Re: freebsd gcc cross compiler creates binaries that crash
> when using c++ exceptions
> 
> On 01/16/2012 10:44 AM, Andrew Haley wrote:
> > On 01/16/2012 09:30 AM, Markus Henschel wrote:
> >> What I did so far was attaching gdb and seeing that it crashes in
> libgcc in __cxa_end_catch. I guess I'll have to build libgcc with debug
> symbols then.
> >
> > This is almost always a mismatch of libraries: there is a complex set
> > of interdependencies between libc, libstdc++, and libgcc.
> 
> By the way, what does a native freebsd gcc do?
> 
> Andrew

When I take the same sources for gcc that produce the "buggy" cross compiler on linux and build it natively on FreeBSD it works as it should. I even used the same --with-sysroot and --prefix switches and copied the freebsd sysroot from the linux machine to make sure I did not mistake when extracting the sysroot and copying it to the linux host in the first place. 

I also created another cross compiler hosted on mingw32 for freebsd from the same sourcen. It fails the same way as the linux hosted one. I also started comparing the config.log files for differences but haven't found something unusual so far.

RE: freebsd gcc cross compiler creates binaries that crash when using c++ exceptions

[Markus Henschel]

> -----Original Message-----
> From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
> Behalf Of Kai Ruottu
> Sent: Montag, 16. Januar 2012 11:54
> To: gcc-help@gcc.gnu.org
> Subject: Re: freebsd gcc cross compiler creates binaries that crash
> when using c++ exceptions
> 
> 16.1.2012 11:30, Markus Henschel kirjoitti:
> 
> > What I did so far was attaching gdb and seeing that it crashes in
> > libgcc
>  > in __cxa_end_catch. I guess I'll have to build libgcc with debug
> symbols  > then.
> 
> There has always been and most probably still is a difference between
> library configures in a native and a cross build. The library
> configures may do some run tests with simple apps. The native target
> system of course can run the test programs the new GCC has compiled and
> linked against the target startups and the standard C library. But the
> cross host as default cannot run anything made for the target system,
> so the configure scripts must know or guess (right) the features the
> target system has!
> 
> So generally the libgcc and libstdc++ configures should know the
> features all the "supported" systems have and produce identical results
> in both native and cross complile cases. Never any "run on target"
> tests done in order to find out how the target system will behave! I
> don't think this already being the case with not so common targets like
> FreeBSD but probably Linux is so well-known and in embedded Linux
> target cases the shared libgcc and libstdc++ will more often be
> produced via crosscompiling than natively. NetBSD and OpenBSD may also
> be embedded targets but FreeBSD, Solaris2 (and other Unices) only
> system targets for which the native compile is the most common...

Thanks for the info. After thinking about it I tried a different approach. Instead of using linux or mingw/msys as build system for the cross compiler I tried FreeBSD. This was quite easy because I already had my own native gcc on FreeBSD and a cross compiler for mingw32 is also available in ports. So I compiled gcc with --host=i386-unkown-freebsd7.1, --target=i386-unkown-freebsd7.1, --host=mingw32 with my native freebsd gcc in PATH. This results in a working mingw32 hosted cross compiler (at least it could successfully compile my test case).