On Thu, 2 May 2024 08:23:38 GMT, Vladimir Petko <vpe...@openjdk.org> wrote:
> Hi, > > The `.type _SafeFetch32_impl,@function` symbol declaration contains a > spurious underscore causing an undefined symbol in libjvm.so. > > I am not sure about change in default flags. I have removed the flag that > allows linking with undefined symbols > because having the flag on might cause bugs like this one or > https://bugs.openjdk.org/browse/JDK-8329983 as the build succeeds even if > some symbols are not defined. > Openjdk builds successfully without it on amd64, i386, armhf, arm64, s390, > ppc64el and riscv64 with this change[1]. riscv64 build was done locally > inside vm: > > Finished building target 'images' in configuration > 'linux-riscv64-server-release' > ubuntu@ubuntu:~/jdk$ > > Unfortunately I do not know why it was introduced, so I might be missing > something. > I am happy to drop it from this one or move it to a separate issue/pr. > > [1] > https://launchpad.net/~vpa1977/+archive/ubuntu/october-21/+sourcepub/16076564/+listing-archive-extra Ok, I think I'm understanding this better now. The error occurs since the `.type`, `.globl` and `.hidden` directives do not match -- we define the global symbol to be `SafeFetch32_impl` but then we set the type of the non-existing symbol `_SafeFetch32_impl`. Somehow this tricks the linker into accepting this as an undefined symbol. The `.type` directive is not without purpose -- it sets the type of the symbol to be a function. If omitted, the type will be `NOTYPE`. Apparently this does not break the program but there is no reason to remove the `.type` directives. Instead, we should have a common macro, something like this: #define DECLARE_FUNC(func) \ .globl func ; \ .hidden func ; \ .type func,@function ; \ func: in a shared file, and include and use it for all symbols in our hotspot assembly files. I was thinking somewhat along those lines last time I was poking around there (when introducing .hidden for the removal of the hotspot map files), but never really got around to it. This bug really shows why we should do that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19048#issuecomment-2100322142
