Multilib with disabled c++ exceptions

Hi Freddie Chopin,

Thanks for the proposal and it's good to hear that it is worth to provide no-exception version of libstdc++ library.
We will see what we can do in following 4.7 major release, even though the no-exception version will not be provided via multilib.

Even with exceptions removed from libstdc++, you will still find the regular libgcc pulling in the unwind code (~10k or so) due to the support for divide-by-zero exceptions in the 64-bit divide helper.

This isn't conditional code; you have to rebuild libgcc manually to remove it, so it can't be multilib'ed easily.

Thx for the info - could you point me to the file that needs to be changed and rebuilt to remove that need for unwind information?

Feddie,

These problems are expected to be solved in 4.7 release. You can apply
following two patches on lastest 4.6 source to build for youself though:

1. Apply following patch to build-toolchain.sh
--- build-toolchain.sh 2012-06-14 01:01:23.000000000 +0800
+++ build-toolchain.nounwind.sh 2012-09-26 11:29:29.479846273 +0800
@@ -221,7 +221,7 @@ $SRCDIR/$GCC/configure --build=$BUILD --
 if [ "x$DEBUG_BUILD_OPTIONS" != "xno" ] ; then
     make CFLAGS="$DEBUG_BUILD_OPTIONS" -j$JOBS
 else
- make -j$JOBS
+ make -j$JOBS CXXFLAGS_FOR_TARGET="-g -Os -ffunction-sections
-fdata-sections -fno-exceptions"
 fi

 make htmldir=$INSTALLDIR_LINUX/share/doc/html
pdfdir=$INSTALLDIR_LINUX/share/doc/pdf
infodir=$INSTALLDIR_LINUX/share/doc/info
mandir=$INSTALLDIR_LINUX/share/doc/man install install-html install-pdf
2. Apply patch in following link to GCC source:
http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01193.html

Thx for the info!

I've rebuilt whole set of libraries (including libgcc) using info above, but when I use 64-bit divides the unwind code gets pulled anyway... I just need to add something like this:

volatile int64_t a, b, c;
a = b / c;

and the unwider is in the disassembly listing. Am I doing something wrong?

You are not doing wrong. It is a known libgcc issue in 64-bit division.
Will be solved in next 4.6 and 4.7 release.

On Wed, Oct 10, 2012 at 11:01 PM, Freddie Chopin <
<email address hidden>> wrote:

> Question #207556 on GCC ARM Embedded changed:
> https://answers.launchpad.net/gcc-arm-embedded/+question/207556
>
> Freddie Chopin posted a new comment:
> I've rebuilt whole set of libraries (including libgcc) using info above,
> but when I use 64-bit divides the unwind code gets pulled anyway... I
> just need to add something like this:
>
> volatile int64_t a, b, c;
> a = b / c;
>
> and the unwider is in the disassembly listing. Am I doing something
> wrong?
>
> --
> You received this question notification because you are an answer
> contact for GCC ARM Embedded.
>

I'm still having this problem with the latest 4.6 stable release (released 21 days after the last answer here was posted). Is this expected to be fixed in the 2013 Q1 version?

With the current version of the library I'm finding it impossible to create a C++ project for cheap Cortex-M0's with 64Kb flash: as soon as any classes are used in the project about 80 Kb of extra code is pulled in from various libraries (the classes are just stubs for testing, no fancy code in there).

Anthony,

4.7 release (targeting end of Q4 2012) will provide a total
library solution for code size sensitive app.

4.6 won't have this new feature since it is in maintenance mode.

Thanks - Joey

On Wed, Nov 28, 2012 at 7:26 AM, Anthony VH <
<email address hidden>> wrote:

> Question #207556 on GCC ARM Embedded changed:
> https://answers.launchpad.net/gcc-arm-embedded/+question/207556
>
> Anthony VH requested more information:
> I'm still having this problem with the latest 4.6 stable release
> (released 21 days after the last answer here was posted). Is this
> expected to be fixed in the 2013 Q1 version?
>
> With the current version of the library I'm finding it impossible to
> create a C++ project for cheap Cortex-M0's with 64Kb flash: as soon as
> any classes are used in the project about 80 Kb of extra code is pulled
> in from various libraries (the classes are just stubs for testing, no
> fancy code in there).
>
> --
> You received this question notification because you are an answer
> contact for GCC ARM Embedded.
>