On Thu, 22 Feb 2024 10:27:06 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with >> compiler options and `JNIEXPORT` on all platforms. >> >> The bug that this PR solves, >> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in >> 2013. Even back then the use of mapfiles in Hotspot was dated, so this is >> really good riddance with old rubbish. >> >> This code touches on central but not well understood parts of the Hotspot >> dynamic library, which has contributed to why this bug has stayed unresolved >> for so long. I will need to explain this fix in more detail than usually >> necessary. (Please bare with me if this gets long.) I also anticipate that >> not all solutions that I've picked will be accepted, and we'll have to >> discuss how to proceed. I think it is better to have actual concrete code to >> discuss around, rather than starting by an abstract discussion. To keep this >> description short, I will post the discussion as a comment to the PR. >> >> I have run this PR through tier 1-3 in our CI system. I have also carefully >> checked how the resulting dynamic library differs with this patch (not much; >> see discussion below). For build system changes, this is often the most >> relevant metric. > > Magnus Ihse Bursie has updated the pull request incrementally with two > additional commits since the last revision: > > - Rename the Windows export file to .def > - Remove unused symbol _Copy_conjoint_bytes on linux/arm32 I just realized I could keep an extremely simplified linker script ("mapfile") for gcc, and thereby keeping the `@SUNWprivate_1.1` on the exported symbols, and keeping `__bss_start` and friends local. This further minimizes the difference to the existing libjvm.so for gcc builds. I think we can get rid of this as well going forward, but as with other cleanups, let's do that separately. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1959467819
