The mailing list requires me to request the feature here. I put it here. https://www.mail-archive.com/gcc@gcc.gnu.org/msg94104.html http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p0709r4.pdf
(In reply to cqwrteur from comment #0) > The mailing list requires me to request the feature here. I put it here. > https://www.mail-archive.com/gcc@gcc.gnu.org/msg94104.html > "However, I desperately need that feature since current C++ exceptions > are totally unusable." Ridiculous claims like "totally unusable" aren't going to convince anybody. > http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p0709r4.pdf This is just a proposal, one of many. It hasn't been approved by the committee and is not without critics. It might be suitable to implement in a branch, as a proof of concept, but most G++ developers are already busy working on things that have actually been approved for inclusion in C++.
(In reply to Jonathan Wakely from comment #1) > (In reply to cqwrteur from comment #0) > > The mailing list requires me to request the feature here. I put it here. > > https://www.mail-archive.com/gcc@gcc.gnu.org/msg94104.html > > > "However, I desperately need that feature since current C++ exceptions > > are totally unusable." > > Ridiculous claims like "totally unusable" aren't going to convince anybody. > > > http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p0709r4.pdf > > This is just a proposal, one of many. It hasn't been approved by the > committee and is not without critics. It might be suitable to implement in a > branch, as a proof of concept, but most G++ developers are already busy > working on things that have actually been approved for inclusion in C++. How to start a branch? It can be an experimental branch, right?
> Ridiculous claims like "totally unusable" aren't going to convince anybody. It is totally unusable. Binary bloat of runtime in bare-metal systems. Relying on stdio.h even stdio.h is not freestanding. C++ EH is thousands of times slower than syscalls on Linux. Any EH thrown is basically a DDOS vulnerability. The worst part is that vector would throw std::length_error/std::bad_alloc/std::bad_array_length which are completely useless tbh.
(In reply to cqwrteur from comment #3) > > Ridiculous claims like "totally unusable" aren't going to convince anybody. > > It is totally unusable. Binary bloat of runtime in bare-metal systems. > Relying on stdio.h even stdio.h is not freestanding. > > C++ EH is thousands of times slower than syscalls on Linux. Any EH thrown is > basically a DDOS vulnerability. > > The worst part is that vector would throw > std::length_error/std::bad_alloc/std::bad_array_length which are completely > useless tbh. BTW. std::terminate() is not thread-safe which is terrible.
(In reply to cqwrteur from comment #4) > (In reply to cqwrteur from comment #3) > > > Ridiculous claims like "totally unusable" aren't going to convince anybody. > > > > It is totally unusable. Binary bloat of runtime in bare-metal systems. > > Relying on stdio.h even stdio.h is not freestanding. > > > > C++ EH is thousands of times slower than syscalls on Linux. Any EH thrown is > > basically a DDOS vulnerability. > > > > The worst part is that vector would throw > > std::length_error/std::bad_alloc/std::bad_array_length which are completely > > useless tbh. > > BTW. std::terminate() is not thread-safe which is terrible. I ban C++ EH every day.
I don't think this is a useful bug report. If/when the proposal gets accepted, it will be useful to track who's working on it, but until then I see no point.
(In reply to Marek Polacek from comment #6) > I don't think this is a useful bug report. If/when the proposal gets > accepted, it will be useful to track who's working on it, but until then I > see no point. I would like to work on it tbh. However, I do not know how to start this branch.
(In reply to Marek Polacek from comment #6) > I don't think this is a useful bug report. If/when the proposal gets > accepted, it will be useful to track who's working on it, but until then I > see no point. Because current C++ exceptions are completely unusable for me. I suffer from it every day. I desperately need to do this on my own.
You can clone the gcc repo as explained here https://gcc.gnu.org/git.html and then start your own local branch.
(In reply to cqwrteur from comment #3) > Relying on stdio.h even stdio.h is not freestanding. Nonsense. (In reply to cqwrteur from comment #4) > BTW. std::terminate() is not thread-safe which is terrible. Nonsense.
(In reply to Jonathan Wakely from comment #10) > (In reply to cqwrteur from comment #3) > > Relying on stdio.h even stdio.h is not freestanding. > > Nonsense. > > (In reply to cqwrteur from comment #4) > > BTW. std::terminate() is not thread-safe which is terrible. > > Nonsense. Functions without thread-safety are always terrible. Like all functions in cctype. They should be avoided like plague.
(In reply to Jonathan Wakely from comment #10) > (In reply to cqwrteur from comment #3) > > Relying on stdio.h even stdio.h is not freestanding. > > Nonsense. stdio.h should not get included in any circumstances for EH. You are implementing the operating system, but you need to enable EH by the standard and EH relies on stdio. Chicken-egg problem.
(In reply to cqwrteur from comment #11) > Functions without thread-safety are always terrible. Like all functions in > cctype. They should be avoided like plague. It's thread-safe though. What are you talking about? (In reply to cqwrteur from comment #12) > stdio.h should not get included in any circumstances for EH. You are > implementing the operating system, but you need to enable EH by the standard > and EH relies on stdio. Chicken-egg problem. It doesn't depend on stdio though. What are you talking about?
(In reply to Jonathan Wakely from comment #13) > (In reply to cqwrteur from comment #11) > > Functions without thread-safety are always terrible. Like all functions in > > cctype. They should be avoided like plague. > > It's thread-safe though. What are you talking about? It calls std::abort() and std::abort() will close FILE* and FILE* might not be thread-safe. BTW std::terminate() is slow compared to compiler intrinsic like __builtin_trap(). > (In reply to cqwrteur from comment #12) > > stdio.h should not get included in any circumstances for EH. You are > > implementing the operating system, but you need to enable EH by the standard > > and EH relies on stdio. Chicken-egg problem. > > It doesn't depend on stdio though. What are you talking about? https://github.com/gcc-mirror/gcc/blob/e11e5d3889f9e54c547efee50fa1b72b50f0f265/libstdc%2B%2B-v3/libsupc%2B%2B/vterminate.cc#L93
> > (In reply to cqwrteur from comment #12) > > > stdio.h should not get included in any circumstances for EH. You are > > > implementing the operating system, but you need to enable EH by the standard > > > and EH relies on stdio. Chicken-egg problem. > > > > It doesn't depend on stdio though. What are you talking about? > > https://github.com/gcc-mirror/gcc/blob/ > e11e5d3889f9e54c547efee50fa1b72b50f0f265/libstdc%2B%2B-v3/libsupc%2B%2B/ > vterminate.cc#L93 Which is disabled in freestanding, and can be optionally disabled in hosted. This is an OPTIONAL feature of libstdc++, not something that exception handling intrinsically relies on. If you don't want it, you don't have to use it. And if you're implementing the OS then you're using freestanding and it's automatically disabled. Looks at line 27 in that file. Once again you are talking out of your backside. Stop wasting our time.
(In reply to Jonathan Wakely from comment #15) > > > (In reply to cqwrteur from comment #12) > > > > stdio.h should not get included in any circumstances for EH. You are > > > > implementing the operating system, but you need to enable EH by the standard > > > > and EH relies on stdio. Chicken-egg problem. > > > > > > It doesn't depend on stdio though. What are you talking about? > > > > https://github.com/gcc-mirror/gcc/blob/ > > e11e5d3889f9e54c547efee50fa1b72b50f0f265/libstdc%2B%2B-v3/libsupc%2B%2B/ > > vterminate.cc#L93 > > Which is disabled in freestanding, and can be optionally disabled in hosted. > > This is an OPTIONAL feature of libstdc++, not something that exception > handling intrinsically relies on. If you don't want it, you don't have to > use it. > > And if you're implementing the OS then you're using freestanding and it's > automatically disabled. Looks at line 27 in that file. > > Once again you are talking out of your backside. > > Stop wasting our time. That does not work in the real-world since your libstdc++'s freestanding header never works correctly, (you get compilation errors). In reality, people just use a "hosted toolchain" with GNU newlib. A "hosted version" of real freestanding. Or you do not even have proper headers to run C++.
(In reply to Jonathan Wakely from comment #15) > > > (In reply to cqwrteur from comment #12) > > > > stdio.h should not get included in any circumstances for EH. You are > > > > implementing the operating system, but you need to enable EH by the standard > > > > and EH relies on stdio. Chicken-egg problem. > > > > > > It doesn't depend on stdio though. What are you talking about? > > > > https://github.com/gcc-mirror/gcc/blob/ > > e11e5d3889f9e54c547efee50fa1b72b50f0f265/libstdc%2B%2B-v3/libsupc%2B%2B/ > > vterminate.cc#L93 > > Which is disabled in freestanding, and can be optionally disabled in hosted. > > This is an OPTIONAL feature of libstdc++, not something that exception > handling intrinsically relies on. If you don't want it, you don't have to > use it. > > And if you're implementing the OS then you're using freestanding and it's > automatically disabled. Looks at line 27 in that file. > > Once again you are talking out of your backside. > > Stop wasting our time. No one wants to tweak around compiler options since compiler options can always break something tbh. There is a reason why C++ is terrible in embedded systems and bare-metal operating systems. What Linus said was totally correct from a kernel dev perspective.
(In reply to cqwrteur from comment #17) > No one wants to tweak around compiler options since compiler options can > always break something tbh. OK, go away and stop wasting our time then. Write your own compiler or your own language and stop being a pain here.
(In reply to cqwrteur from comment #16) > That does not work in the real-world since your libstdc++'s freestanding > header never works correctly, (you get compilation errors). Try reporting a bug about *that* next time (except don't, I don't want any more stupidity from you).
(In reply to Jonathan Wakely from comment #19) > (In reply to cqwrteur from comment #16) > > That does not work in the real-world since your libstdc++'s freestanding > > header never works correctly, (you get compilation errors). > > Try reporting a bug about *that* next time (except don't, I don't want any > more stupidity from you). Let me be more clear. 1. Freestanding C++ in the current situation is very problematic. (You do not have memcpy, you do not have std::move. You do not have std::forward. You do not have std::addressof(). you do not have std::array.) However, you have an exception handling support. 2. What's the point of reporting a bug when building libstdc++ with GNU newlib just works much better and you have an entire hosted toolchain that will not break compilation? The only problem is that you never enable EH. I did report bugs before. However, it was not fixed. I am not going to try it again tbh since newlib works just fine. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1105r0.html Bare metal gcc 4.8 with newlib undefined reference to "__exidx_end" undefined reference to "__exidx_start" undefined reference to "_exit" undefined reference to "_sbrk" undefined reference to "_kill" undefined reference to "_getpid" undefined reference to "_write" undefined reference to "_close" undefined reference to "_fstat" undefined reference to "_isatty" undefined reference to "_lseek" undefined reference to "_read"
(In reply to cqwrteur from comment #20) > (In reply to Jonathan Wakely from comment #19) > > (In reply to cqwrteur from comment #16) > > > That does not work in the real-world since your libstdc++'s freestanding > > > header never works correctly, (you get compilation errors). > > > > Try reporting a bug about *that* next time (except don't, I don't want any > > more stupidity from you). > > Let me be more clear. That would be a welcome change from your usual nonsense. > 1. Freestanding C++ in the current situation is very problematic. (You do > not have memcpy, you do not have std::move. You do not have std::forward. > You do not have std::addressof(). you do not have std::array.) However, you > have an exception handling support. But no dependency on stdio. > 2. What's the point of reporting a bug when building libstdc++ with GNU So it can be fixed, duh. > newlib just works much better and you have an entire hosted toolchain that > will not break compilation? The only problem is that you never enable EH. > I did report bugs before. However, it was not fixed. I am not going to try > it again tbh since newlib works just fine. Great. So build with --disable-libstdcxx-verbose as well and stop complaining about a feature that other people find useful. Maybe we should make that the default for --with-newlib builds. That might be a useful improvement. More useful than your usual hyperbole and timewasting anyway.
(In reply to cqwrteur from comment #20) > 1. Freestanding C++ in the current situation is very problematic. (You do > not have memcpy, you do not have std::move. You do not have std::forward. > You do not have std::addressof(). Freestanding libstdc++ provides std::move, std::forward and std::addressof.
And memcpy must be provided as documented in the GCC documentation: Most of the compiler support routines used by GCC are present in @file{libgcc}, but there are a few exceptions. GCC requires the freestanding environment provide @code{memcpy}, @code{memmove}, @code{memset} and @code{memcmp}. Finally, if @code{__builtin_trap} is used, and the target does not implement the @code{trap} pattern, then GCC emits a call to @code{abort}.
(In reply to Jonathan Wakely from comment #22) > (In reply to cqwrteur from comment #20) > > 1. Freestanding C++ in the current situation is very problematic. (You do > > not have memcpy, you do not have std::move. You do not have std::forward. > > You do not have std::addressof(). > > Freestanding libstdc++ provides std::move, std::forward and std::addressof. But that is actually not standard compliant. You may end up with another toolchain that does not provide those facilities and you have troubles now. The only option is to use newlib basically and that is why newlib is nowadays the standard libc for embedded systems.
> > 1. Freestanding C++ in the current situation is very problematic. (You do > > not have memcpy, you do not have std::move. You do not have std::forward. > > You do not have std::addressof(). you do not have std::array.) However, you > > have an exception handling support. > > But no dependency on stdio. That does not mean it has no dependency. It depends on malloc/free which is something you cannot avoid at all. BTW, there are other issues with the implementation EH unwinder, it walks stack twice for just more debugging information. Guess what is the information consumed for? They output to stdio lol. Your termination with multiple fputs calls also has issues even in a hosted environment. Because it is not process-safe. When multiple processes throw eh at the same time, they end up corrupting log files. (I did see that when i was doing testing on the burden of multiple process TCP servers.) I guess changing that to writev(2) might solve part of the problems but writev(2) does not guarantee process safety for console or other I/O devices. > > > 2. What's the point of reporting a bug when building libstdc++ with GNU > > So it can be fixed, duh. > > > newlib just works much better and you have an entire hosted toolchain that > > will not break compilation? The only problem is that you never enable EH. > > I did report bugs before. However, it was not fixed. I am not going to try > > it again tbh since newlib works just fine. > > Great. So build with --disable-libstdcxx-verbose as well and stop > complaining about a feature that other people find useful. > > Maybe we should make that the default for --with-newlib builds. That might > be a useful improvement. More useful than your usual hyperbole and > timewasting anyway. I mean you can try to fix it a little. However, it breaks ABI. The effort does not worth the cost. More fundamental issues like binary bloat would never get fixed. Unfortunately, the C++ compiler does not remove dead virtual functions. The entire C++ exceptions are built on virtual function calls. That stuff all add bloat you do not want. Recently I just remove one virtual method of EH and the binary size reduces 50KB for hello world. If the exceptions are just designed for termination, it is nowhere better than killing the process and restarted it again. (With __builtin_trap() you even get higher performance than EH in the happy path because it reduces the burden of CPU instruction cache) For servers hosted on the internet, using EH is a disaster since it is basically DDOS. The attacker can inject invalid input to make the process keep throwing EH which ends up crashing. (There are security papers talking about that. I can even show you). EH does not work for cryptography either since cryptography requires deterministic. Any gap between timing can be a side-channel.
(In reply to cqwrteur from comment #24) > (In reply to Jonathan Wakely from comment #22) > > (In reply to cqwrteur from comment #20) > > > 1. Freestanding C++ in the current situation is very problematic. (You do > > > not have memcpy, you do not have std::move. You do not have std::forward. > > > You do not have std::addressof(). > > > > Freestanding libstdc++ provides std::move, std::forward and std::addressof. > > But that is actually not standard compliant. I think what you mean is it's not portable and strictly compliant code can't rely on it. It's is standard compliant for our freestanding mode to provide more than the minimum required. But portable code can't rely on deterministict exceptions either, yet you insist that it's essential and you can't live without it. It seems you're quite happy to rely on non-standard things when it suits you, but when it doesn't it's completely unusable. Because you're a timewaster. (In reply to cqwrteur from comment #25) > I mean you can try to fix it a little. However, it breaks ABI. So do deterministic exceptions. Please go away and write your own compiler or language.
> But portable code can't rely on deterministict exceptions either, yet you > insist that it's essential and you can't live without it. It seems you're > quite happy to rely on non-standard things when it suits you, but when it > doesn't it's completely unusable. Because you're a timewaster. It will be portable when it is a part of the C++ standard. > (In reply to cqwrteur from comment #25) > > I mean you can try to fix it a little. However, it breaks ABI. > > So do deterministic exceptions. It does not. No existing code will be broken because of deterministic exceptions. > Please go away and write your own compiler or language. Rust folks did that. Are you happy with it? I have no interest in writing my own compiler or language. I am more interested in how to fixing existing things. I was a lover of C++ EH and I completely hate C++ exceptions when I understand the ugliness beneath it. That is why deterministic exceptions are important. Same with C++ iostream, they need to be replaced with something else too.
(In reply to cqwrteur from comment #27) > > But portable code can't rely on deterministict exceptions either, yet you > > insist that it's essential and you can't live without it. It seems you're > > quite happy to rely on non-standard things when it suits you, but when it > > doesn't it's completely unusable. Because you're a timewaster. > > It will be portable when it is a part of the C++ standard. > > > (In reply to cqwrteur from comment #25) > > > I mean you can try to fix it a little. However, it breaks ABI. > > > > So do deterministic exceptions. > > It does not. No existing code will be broken because of deterministic > exceptions. > > > Please go away and write your own compiler or language. > > Rust folks did that. Are you happy with it? > > I have no interest in writing my own compiler or language. I am more > interested in how to fixing existing things. I was a lover of C++ EH and I > completely hate C++ exceptions when I understand the ugliness beneath it. > That is why deterministic exceptions are important. > > Same with C++ iostream, they need to be replaced with something else too. That is why Herb Sutter said "digging the hole we already jumped into". Those fixing makes nonsense, to be honest.
(In reply to Jakub Jelinek from comment #23) > And memcpy must be provided as documented in the GCC documentation: > Most of the compiler support routines used by GCC are present in > @file{libgcc}, but there are a few exceptions. GCC requires the > freestanding environment provide @code{memcpy}, @code{memmove}, > @code{memset} and @code{memcmp}. > Finally, if @code{__builtin_trap} is used, and the target does > not implement the @code{trap} pattern, then GCC emits a call > to @code{abort}. I am sure I did not understand anything wrong. The rule is simple, if you use gcc, you must use libgcc. libgcc provides those facilities. https://wiki.osdev.org/Libgcc __builtin_trap() is always faster than std::terminate(), even it actually emits a call to std::abort(), because std::terminate() requires atomic to sync the terminate_handler. The problem with std::terminate() is that it does not work like operator new where it is weak alias. You still get bloat and dependency to std::abort() even you are using set_terminate_handle(). if we are using __builtin_trap() on platforms like x86_64, they emit ud instructions and use that to terminate is fast and avoid dependency on libc, (particularly we mean glibc here.)
> Great. So build with --disable-libstdcxx-verbose as well and stop > complaining about a feature that other people find useful. But even GCC bootstraps itself with EH, RTTI disabled (of course you are not allowed to use iostream either). How could you convince other people they are actually useful? They are broken tbh.
.