On 13/05/2020 00:48, Jonathan Wakely via Gcc wrote:
On Tue, 12 May 2020 at 23:39, Jonathan Wakely wrote:
On Tue, 12 May 2020, 21:57 Freddie Chopin, <freddie_cho...@op.pl> wrote:
Anyway... If you have to recompile the toolchain, the problem is still
there. Most of the people (like 99,666%) will not do that for various
reasons. Some don't know how, some use only Windows, some don't have
time to deal with the compilation (the whole toolchain takes around an
hour here, but this excludes the time to prepare the script that builds
it), some other consider the toolchain provided by MCU vendor (or by
ARM) as "tested to work correctly" so they don't want to replace that
with their custom built solution, and so on, and so on...
There is no one-size-fits-all solution that gives everybody their
ideal set of defaults, so we provide configuration options to tune
things for your needs. Complaining that you have to rebuild things to
get different defaults seems silly. Would you prefer we don't offer
the options at all?
And I also never said that every user should rebuild the toolchain.
The options can be used by vendors providing a toolchain for their
hardware, if the verbose handler (or exceptions in general!) are not
appropriate for their users. Just because something isn't the default,
doesn't mean every user needs to change it themselves.
I think complaining about extra unnecessary code (such as string
handling for std::terminate) is justified - but the complaints should
not be directed at the gcc or libstdc++ folks. As you say, /you/
provide the options - if the vendors make poor choices of options, then
it is /they/ who should get the bug reports and complaints.
One option that would be nice (I don't know if it is realistic), would
be to say that the code should never stop normally. On many embedded
systems, main() never exits. std::terminate() doesn't need any code
except perhaps to reset the processor (that will be target-specific, of
course). exit() can never be called - there is no need for atexit
functions, terminate handlers, global destructors, or any of the other
machinery used for controlled shutdown and ending of a program.
And if writing a script and waiting an hour is too much effort to
reduce unwanted overhead, then I guess that overhead isn't such a big
deal anyway.
There are, as Freddie mentions, many other reasons for end-users not
building their own toolchains. I have built many cross-gcc toolcahins
over the years (starting with a gcc 2.95 m68k toolchain over 20 years
ago, IIRC). But for most professional embedded development, pre-built
toolchains from vendors are a requirement - home-built is simply not an
acceptable option. Time and effort don't come into it. (This is a good
thing for gcc - a fair number of major gcc developers work for companies
that earn money selling pre-built toolchains.)
