[aarch64-port-dev ] RFR(XS) 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__

[Kim Barrett]

> On Jul 14, 2020, at 5:11 PM, Monica Beckwith <Monica.Beckwith at microsoft.com> wrote:
> 
> Hi all,
> 
> Please review the change for MSVC, which doesn't have the __PRETTY_FUNCTION__ macro. 
> I have instead added __FUNCSIG__ within appropriate #ifdef and also added the following comments:
> 
> +// Microsoft's MSVC team thinks that the __FUNCSIG__ is approximately (sympathy for calling conventions) equivalent to __PRETTY_FUNCTION__
> +// Also, from the Clang patch: "It is very similar to GCC's PRETTY_FUNCTION, except it prints the calling convention."
> +// https://reviews.llvm.org/D3311
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8248681
> Webrev: http://cr.openjdk.java.net/~mbeckwit/8248681/webrev.00/
> 
> Regards,
> Monica

Not so much a review as a comment / suggested alternative.

There is a general preference in HotSpot code toward avoiding
toolchain-specific conditional compilation in shared code. (Obviously
this is not a hard and fast rule.) This is even called out in the
HotSpot Style Guide. Before the MSVC/aarch64 port the code being
modified by this change is gcc-specific rather than shared, but with
that port it becomes shared.

It seems like this might be a case where we should have some macro
defined somewhere like globalDefinitions_xxx.hpp that for gcc/clang
expands to __PRETTY_FUNCTION__ and for MSVC expands to __FUNCSIG__.
(Probably with a default expansion to __func__ since we should very
shortly have C++11/14.)

Of course, this is currently the only use of __PRETTY_FUNCTION__ in
all of HotSpot, so that might be considered excessive overhead.  But
if we had such a macro it would simplify (and so perhaps encourage)
the use of this feature.