* [musl] add noexcept to all functions please @ 2021-11-06 17:15 sotrdg sotrdg 2021-11-06 18:28 ` Jon Chesterfield 0 siblings, 1 reply; 7+ messages in thread From: sotrdg sotrdg @ 2021-11-06 17:15 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 362 bytes --] cpp-noexcept_call/README.md at main · tearosccebe/cpp-noexcept_call (github.com)<https://github.com/tearosccebe/cpp-noexcept_call/blob/main/README.md> The compiler does NOT treat the libc functions as noexcept functions in C++. They do not. In fact I have got bitten by this. Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows [-- Attachment #2: Type: text/html, Size: 1903 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [musl] add noexcept to all functions please 2021-11-06 17:15 [musl] add noexcept to all functions please sotrdg sotrdg @ 2021-11-06 18:28 ` Jon Chesterfield 2021-11-06 18:39 ` Joakim Sindholt 0 siblings, 1 reply; 7+ messages in thread From: Jon Chesterfield @ 2021-11-06 18:28 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 574 bytes --] That's a compiler bug, surely. A C function that takes no callbacks is not going to throw. On Sat, 6 Nov 2021, 17:56 sotrdg sotrdg, <euloanty@live.com> wrote: > cpp-noexcept_call/README.md at main · tearosccebe/cpp-noexcept_call > (github.com) > <https://github.com/tearosccebe/cpp-noexcept_call/blob/main/README.md> > > > > The compiler does NOT treat the libc functions as noexcept functions in > C++. They do not. In fact I have got bitten by this. > > > > > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows > > > [-- Attachment #2: Type: text/html, Size: 1319 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [musl] add noexcept to all functions please 2021-11-06 18:28 ` Jon Chesterfield @ 2021-11-06 18:39 ` Joakim Sindholt 2021-11-07 17:37 ` James Y Knight 0 siblings, 1 reply; 7+ messages in thread From: Joakim Sindholt @ 2021-11-06 18:39 UTC (permalink / raw) To: musl On Sat, Nov 06, 2021 at 06:28:31PM +0000, Jon Chesterfield wrote: > That's a compiler bug, surely. A C function that takes no callbacks is not > going to throw. I don't think the compiler can prove that. As far as I know the extern "C" {} that C headers get wrapped in for C++ just means the compiler doesn't type-mangle function names. The function itself can not only throw by itself but it can also call other functions that throw as part of its implementation. If there's a compiler bug here it would have to be that it discards knowledge about C standard functions that can indeed not throw. I don't know if that's the case here, or if it's just nonstandard functions that are affected. FWIW I don't think musl should tag any functions with anything just to make C++ marginally faster. This seems like a case of C++ getting hoisted by its own petard. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [musl] add noexcept to all functions please 2021-11-06 18:39 ` Joakim Sindholt @ 2021-11-07 17:37 ` James Y Knight 2021-11-07 18:20 ` Florian Weimer 0 siblings, 1 reply; 7+ messages in thread From: James Y Knight @ 2021-11-07 17:37 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 2166 bytes --] On Sat, Nov 6, 2021 at 2:40 PM Joakim Sindholt <opensource@zhasha.com> wrote: > On Sat, Nov 06, 2021 at 06:28:31PM +0000, Jon Chesterfield wrote: > > That's a compiler bug, surely. A C function that takes no callbacks is > not > > going to throw. > > I don't think the compiler can prove that. As far as I know the extern > "C" {} that C headers get wrapped in for C++ just means the compiler > doesn't type-mangle function names. The function itself can not only > throw by itself but it can also call other functions that throw as part > of its implementation. That's correct. In general, extern "C" functions are allowed to throw. > If there's a compiler bug here it would have to be that it discards > knowledge about C standard functions that can indeed not throw. I don't > know if that's the case here, or if it's just nonstandard functions that > are affected. Some of the common standard functions are detected and treated specially by compilers. Such libc functions that have special-casing are already generally treated as non-throwing by both GCC and Clang. However, there are a _lot_ of libc functions, both standard and nonstandard, that the compiler doesn't hardcode any knowledge about. > FWIW I don't think musl should tag any functions with anything just to > make C++ marginally faster. This seems like a case of C++ getting > hoisted by its own petard. > I have no horse in this race, but that really seems not a very helpful attitude. There's a large number of users of libc who are using C++ rather than C -- and many (most?) of them are compiling with exceptions enabled. If adding minor cruft to all of the libc function declarations will make a meaningful difference to all of that code's performance, that seems well worth considering, regardless of anyone's opinions regarding decisions about how to implement exceptions in C++ that were made 30 years ago. Glibc defines macros for this purpose, which expand into "throw()" in C++ and "__attribute__((__nothrow__))" in GCC-C. The latter is only useful in conjunction with an extremely-rarely-used feature, C code built with -fexceptions enabled, and is thus probably ignorable. [-- Attachment #2: Type: text/html, Size: 2983 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [musl] add noexcept to all functions please 2021-11-07 17:37 ` James Y Knight @ 2021-11-07 18:20 ` Florian Weimer 2021-11-07 19:56 ` Markus Wichmann 0 siblings, 1 reply; 7+ messages in thread From: Florian Weimer @ 2021-11-07 18:20 UTC (permalink / raw) To: James Y Knight; +Cc: musl * James Y. Knight: > Glibc defines macros for this purpose, which expand into "throw()" in > C++ and "__attribute__((__nothrow__))" in GCC-C. The latter is only > useful in conjunction with an extremely-rarely-used feature, C code > built with -fexceptions enabled, and is thus probably ignorable. We build our distributions with -fexceptions -fasynchronous-unwind-tables. These features have real uses out there (although -fasynchronous-unwind-tables is probably more important for performance analysis and diagnostics). With glibc, -fexceptions is desirable to avoid unprotected function pointers on the stack in conjunction with POSIX cancellation handlers (which can be relevant even if unwinding does not happen). I believe the musl cancellation implementation does not use DWARF unwinding. I do not know if it cancellation handlers have the same hardening gap as glibc's with setjmp-based unwinding. Thanks, Florian ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [musl] add noexcept to all functions please 2021-11-07 18:20 ` Florian Weimer @ 2021-11-07 19:56 ` Markus Wichmann 2021-11-08 8:30 ` Florian Weimer 0 siblings, 1 reply; 7+ messages in thread From: Markus Wichmann @ 2021-11-07 19:56 UTC (permalink / raw) To: musl On Sun, Nov 07, 2021 at 07:20:21PM +0100, Florian Weimer wrote: > I believe the musl cancellation implementation does not use DWARF > unwinding. I do not know if it cancellation handlers have the same > hardening gap as glibc's with setjmp-based unwinding. > > Thanks, > Florian > I presume you mean the cancel cleanup handling. In that case, musl uses a simple linked list, with nodes allocated on stack. No gaps of any kind. Ciao, Markus ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [musl] add noexcept to all functions please 2021-11-07 19:56 ` Markus Wichmann @ 2021-11-08 8:30 ` Florian Weimer 0 siblings, 0 replies; 7+ messages in thread From: Florian Weimer @ 2021-11-08 8:30 UTC (permalink / raw) To: Markus Wichmann; +Cc: musl * Markus Wichmann: > On Sun, Nov 07, 2021 at 07:20:21PM +0100, Florian Weimer wrote: >> I believe the musl cancellation implementation does not use DWARF >> unwinding. I do not know if it cancellation handlers have the same >> hardening gap as glibc's with setjmp-based unwinding. > I presume you mean the cancel cleanup handling. In that case, musl uses > a simple linked list, with nodes allocated on stack. No gaps of any > kind. The __f function pointer is stored in the node on the stack, along with the __x argument that is passed by _pthread_cleanup_pop. This looks like a convenient on-stack gadget for exploitation purposes. In musl, the invocation is in the library itself, so there isn't much choice there. In glibc, with -fno-exceptions, we try to avoid this by inlining the non-cancellation path at the pthread_cleanup_pop point. But even if the function pointer is constant, current GCC is no longer able to produce a direct call. But with -fexceptions, we do get a direct call. Thanks, Florian ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-11-08 8:30 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-11-06 17:15 [musl] add noexcept to all functions please sotrdg sotrdg 2021-11-06 18:28 ` Jon Chesterfield 2021-11-06 18:39 ` Joakim Sindholt 2021-11-07 17:37 ` James Y Knight 2021-11-07 18:20 ` Florian Weimer 2021-11-07 19:56 ` Markus Wichmann 2021-11-08 8:30 ` Florian Weimer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ 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 NNTP newsgroup(s).