RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK static linking
Jiangli Zhou
jiangli at openjdk.org
Wed Jan 24 22:33:28 UTC 2024
On Wed, 24 Jan 2024 09:29:16 GMT, Andrew Haley <aph at openjdk.org> wrote:
> > > I think you should be able to use ld and objcopy to merge the .o files and hide all of the symbols you don't want to export.
> >
> >
> > We also discussed about `objcopy` in [#14808 (comment)](https://github.com/openjdk/jdk/pull/14808#issuecomment-1631597197) and [#14808 (comment)](https://github.com/openjdk/jdk/pull/14808#issuecomment-1631611220). My main concern was the portability of `objcopy` approach.
>
> I replied:
>
> OK, but it is the right thing to do on Linux. If some other operating systems don't provide useful tools, that's on them. I haven't checked, but I strongly suspect that LLVM can do it too, so all that remains is Windows, and maybe they can't have static linking (or maybe they have to use something like this PR) until the right tooling is provided.
>
> If Windows really can't do it, that's no reason to burden systems that can. Namespaces are not a low-cost solution for developers.
Thanks, @theRealAph.
Yeah, I was mainly concerned about non-unix like systems, Windows particularly. It might not work on all potentially supported compilers (`gcc`) on linux, however. To localizing symbols in `libjvm` using `objcopy`, we can first partially link (with `-r`) all hotspot `.o` into a single object file, then run `objcopy` for the output object file to localize the affected symbols. The partial linking work (https://github.com/openjdk/jdk/blob/2003610b3b52eed04de6713a2a36151d0d86d7c9/make/common/NativeCompilation.gmk#L1245) has been added already. However, during the https://github.com/openjdk/jdk/pull/14064 work, we ran into issues with partial linking on older `gcc` for linux-aarch64. The details were captured in https://github.com/openjdk/jdk/pull/14064#issuecomment-1564908324 discussion with @erikj79. Only `clang` currently work well with the partial linking and symbol localizing solution.
Maybe we could live with symbol redefinition using #define (conditionally for static linking in OpenJDK, as Coleen suggested earlier) for now, until the tooling can support symbol localizing better. Then localizing symbols using tools like `objcopy` can be the longer term and cleaner solution, instead of using namespace. What's your thoughts on that?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1909019550
More information about the serviceability-dev
mailing list