public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: Oleg Endo <oleg.endo@t-online.de>
Cc: "Freddie Chopin" <freddie_chopin@op.pl>,
	"Moritz Strübe" <moritz.struebe@redheads.de>,
	"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: size of exception handling (Was: performance of exception handling)
Date: Wed, 13 May 2020 10:13:22 +0100	[thread overview]
Message-ID: <CAH6eHdR9RZutHMi_uYkFCMu6QkYTNSHQuZSxxHVkqjpAF9Ks4w@mail.gmail.com> (raw)
In-Reply-To: <1d337e51bd23c4c56249a184e2b741c0ea6a9954.camel@t-online.de>

On Tue, 12 May 2020, 10:15 Oleg Endo, <oleg.endo@t-online.de> wrote:
>
> On Tue, 2020-05-12 at 09:20 +0200, Freddie Chopin wrote:
> >
> > I actually have to build my own toolchain instead of the one provided
> > by ARM, because to really NOT use C++ exceptions, you have to recompile
> > the whole libstdc++ with `-fno-exceptions -fno-rtti` (yes, I know they
> > provide the "nano" libraries, but I the options they used for newlib
> > don't suit my needs - this is "too minimized"). If you pass these two
> > flags during compilation and linking of your own application, this
> > disables these features only in your code. As libstdc++ is compiled
> > with exceptions and RTTI enabled, ...
>
> IMHO this is a conceptual fail of the whole concept of using pre-
> compiled pre-installed libraries somewhere in the toolchain, in
> particular for this kind of cross-compilation scenario.


The concept works well in other scenarios though. Not everybody has
the same use case or the same needs.


>   Like you say,
> when we set "exceptions off" it usually means for the whole embedded
> app, and the whole embedded app usually means all the OS and runtime
> libraries and everything, not just the user code.
>
> One option is to not use the pre-compiled toolchain libstc++ but build
> it from source (or use another c++ std lib of your choice), as part of
> the whole project, with the desired project settings.


Yes, IMO that's probably the right option if there is no pre-compiled
toolchain that matches your desired configuration.

If there are properties of libstdc++ that make it more difficult than
necessary, we want to know about them.


>
> BTW, just to throw in my 2-cents into the "I'm using MCU" pool of
> pain/joy ... in one of my projects I'm using STM32F051K6U6, 32 KB
> flash, 8 KB RAM, running all C++ code with shared C++ RPC libraries to
> communicate with other (bigger) devices.  Exceptions, RTTI, threads
> have to be turned off and only the header-only things from the stdlib
> can be used and no heap allocations.


Are you using headers that are not part of the freestanding subset? Which ones?

A future version of the C++ standard is probably going to expand the
headers that should be part of freestanding (or replace the concept of
freestanding with something more useful) so it would be good to know
what parts of the standard library people are actually using on
devices like that.


> Otherwise the thing doesn't fit.
> Don't feel like rewriting the whole thing either.  There are some
> annoyances when turning off exceptions and RTTI which results in
> increased code maintenance.


Such as?


> I'd definitely be good and highly
> appreciated if there were any improvements in the area of exception
> handling.
>
> Cheers,
> Oleg
>

  reply	other threads:[~2020-05-13  9:13 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-11  8:14 performance of exception handling Thomas Neumann
2020-05-11 10:40 ` Florian Weimer
2020-05-11 13:59   ` Thomas Neumann
2020-05-11 14:22     ` Florian Weimer
2020-05-11 15:14     ` size of exception handling (Was: performance of exception handling) Moritz Strübe
2020-05-12  7:20       ` Freddie Chopin
2020-05-12  7:47         ` Oleg Endo
2020-05-13  9:13           ` Jonathan Wakely [this message]
2020-05-12  9:16         ` size of exception handling Florian Weimer
2020-05-12  9:44           ` Freddie Chopin
2020-05-12 11:11             ` Jonathan Wakely
2020-05-12 11:17             ` Moritz Strübe
2020-05-12 11:29               ` Florian Weimer
2020-05-12 12:01                 ` Moritz Strübe
2020-05-12 11:07         ` size of exception handling (Was: performance of exception handling) Jonathan Wakely
2020-05-12 20:56           ` Freddie Chopin
2020-05-12 22:39             ` Jonathan Wakely
2020-05-12 22:48               ` Jonathan Wakely
2020-05-13  8:04                 ` David Brown
2020-05-12  9:03       ` size of exception handling Florian Weimer
2020-05-11 14:36   ` performance " David Edelsohn
2020-05-11 14:52     ` Florian Weimer
2020-05-11 15:12       ` David Edelsohn
2020-05-11 15:24         ` Florian Weimer
2020-05-12  6:08     ` Thomas Neumann
2020-05-12  7:15       ` Richard Biener
2020-05-12  7:30         ` Thomas Neumann
2020-05-12  9:01       ` Richard Sandiford
2020-05-13  1:13         ` Thomas Neumann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAH6eHdR9RZutHMi_uYkFCMu6QkYTNSHQuZSxxHVkqjpAF9Ks4w@mail.gmail.com \
    --to=jwakely.gcc@gmail.com \
    --cc=freddie_chopin@op.pl \
    --cc=gcc@gcc.gnu.org \
    --cc=moritz.struebe@redheads.de \
    --cc=oleg.endo@t-online.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).