[libitm] eh specifications are lax

Nathan Sidwell nathan@acm.org
Tue May 5 20:08:27 GMT 2020


I discovered that libitm:
(a) declares __cxa_allocate_exception and friends directly,
(b) doesn't mark them as 'throw()'
(c) doesn't mark the replacment fns _ITM_$foo as nothrow either

We happen to get away with it because of code in the compiler that, 
although it checks the parameter types, doesn't check the exception 
specification.  (One reason being they used to not be part of the 
language's type system, but now they are.)  I suspect this can lead us 
to generate pessimal code later, if we've seen one of these decls 
earlier.  Anyway, with modules it becomes trickier[*], so I'm trying to 
clean it up and not be a problem.  I see Jakub fixed part of the problem 
(https://gcc.gnu.org/pipermail/gcc-patches/2018-December/513302.html) 
AFAICT, he did fix libitm's decls, but left the lax parm-type checking 
in the compiler.

libitm.h is not very informative about specification:
   in version 1 of http://www.intel.com/some/path/here.pdf.  */

Anyway, it was too fiddly to have libitm pick up the declarations from 
libsupc++.  Besides it makes them weak declarations, and then provides 
definitions for non-elf systems.  So this patch adds the expected 'throw()'

While I can't be sure, I suspect the _ITM entry points are supposed to 
have the same exception specification as the original entry points.  So 
those are also made 'throw ()'.  libstdc++'s _GLIBCXX_NOTHROW didn't 
seem available, so I make use of a new _ITM_NOTHROW macro, suitably defined.

Because of the lax checking in the compiler, and old compiler with a 
patched libitm.h will be ok...  Until I change the compiler :)

booted & tested on x86_64-linux, ok?

nathan

[*] modules make it harder to have ODR violations, that's why it finds 
ODR violations in existing code.

-- 
Nathan Sidwell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eh.diff
Type: text/x-patch
Size: 4661 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20200505/79acbb72/attachment.bin>


More information about the Gcc-patches mailing list