Simplifying the poisoning mechanism used in HotSpot
Kim Barrett
kim.barrett at oracle.com
Mon Aug 18 01:48:50 UTC 2025
On 8/17/25 2:53 PM, Julian Waters wrote:
> With a simple function macro redirection, you could reroute calls to, say,
> malloc, [...] does come with one drawback, namely that any declarations (Not
> just calls!) of a method with the same name in any of our code [...] will be
> overwritten as well.
The need to undef the `malloc` macro in order to call `os::malloc` is the
classic problem of macros being unscoped. There are going to be lots of that
sort of thing. And not just for function calls and declarations. For example,
the `exit` function (<stdlib.h>) is poisoned, and there are variables with
that name (it's a common label name in macroAssembler code, for example). I
think this is a deal breaker for any such approach.
> Arguably the biggest downside of this system is the fact that you need to
> select the exact correct macro to use for forbidding any methods in the
> codebase (There are several)
I don't see a way to avoid that with a redeclaration-based poisoning
mechanism. And all of the other mechanisms I looked at had much worse
problems.
I know of two issues with the current mechanism, both involving clang.
One has already been fixed, with the fix probably in clang 21. So someday we
should be able to remove our workaround for that one. And it's just a warning
suppression in an appropriate place. See
FORBIDDEN_FUNCTION_IGNORE_CLANG_FORTIFY_WARNING.
The other is that clang does something that is at least not useful, and is
arguably just wrong, in the interaction between its compiler-specific noreturn
attribute and the standard noreturn attribute. This is what leads to the
annoying workarounds discussed in the opening of this thread. Unfortunately,
some of the clang developers weren't convinced. See discussion in the bug
referenced in the comment for FORBIDDEN_FUNCTION_NORETURN_ATTRIBUTE.
Our clang workarounds could be removed if clang were changed as suggested
(making it like MSVC and gcc in the relevant behavior). I don't know if that's
ever going to happen. :( Maybe someone with more influence in that community
than I have could take up the cause here.
More information about the hotspot-dev
mailing list