mailing list of musl libc
 help / color / mirror / code / Atom feed
* [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).