From jiangli at openjdk.org Fri Apr 7 23:55:54 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 7 Apr 2023 23:55:54 GMT Subject: jmx-dev RFR: 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries Message-ID: Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries. 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries ------------- Commit messages: - Resolve linker failure due to multiple definition of 'jvm' when statically linking with JDK native libraries. Changes: https://git.openjdk.org/jdk/pull/13396/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13396&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305761 Stats: 130 lines in 5 files changed: 82 ins; 0 del; 48 mod Patch: https://git.openjdk.org/jdk/pull/13396.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13396/head:pull/13396 PR: https://git.openjdk.org/jdk/pull/13396 From jiangli at openjdk.org Sat Apr 8 00:04:57 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Sat, 8 Apr 2023 00:04:57 GMT Subject: jmx-dev Withdrawn: 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries In-Reply-To: References: Message-ID: On Fri, 7 Apr 2023 23:32:46 GMT, Jiangli Zhou wrote: > Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries. > > 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/13396 From jiangli at openjdk.org Sat Apr 8 01:19:44 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Sat, 8 Apr 2023 01:19:44 GMT Subject: jmx-dev RFR: 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries Message-ID: ? with JDK native libraries ------------- Commit messages: - 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries Changes: https://git.openjdk.org/jdk/pull/13397/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13397&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305761 Stats: 36 lines in 5 files changed: 0 ins; 0 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/13397.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13397/head:pull/13397 PR: https://git.openjdk.org/jdk/pull/13397 From phaidinyak at cox.net Sat Apr 8 00:20:40 2023 From: phaidinyak at cox.net (phaidinyak at cox.net) Date: Fri, 7 Apr 2023 20:20:40 -0400 Subject: jmx-dev Stupid question In-Reply-To: References:

Message-ID: <012401d969af$f4204890$dc60d9b0$@cox.net> Hi, Now that I'm retired I'm getting back to a project I started in the 2000's. Back then I was using JMX for notifications and the MLET feature. Is MLET still a 'thing' now? If not is there a recommended process for loading Object, other than taking a .mlet type file and loading them by hand. Thanks -Pete From kevin.walls at oracle.com Sat Apr 8 09:26:07 2023 From: kevin.walls at oracle.com (Kevin Walls) Date: Sat, 8 Apr 2023 09:26:07 +0000 Subject: jmx-dev Stupid question In-Reply-To: <012401d969af$f4204890$dc60d9b0$@cox.net> References:

<012401d969af$f4204890$dc60d9b0$@cox.net> Message-ID: Hi, The MLET feature has been deprecated in JDK20, for future removal. There is no replacement feature. The rest of JMX and Notifications are unchanged. Thanks Kevin -----Original Message----- From: jmx-dev On Behalf Of phaidinyak at cox.net Sent: 08 April 2023 01:21 To: jmx-dev at openjdk.org Subject: jmx-dev Stupid question Hi, Now that I'm retired I'm getting back to a project I started in the 2000's. Back then I was using JMX for notifications and the MLET feature. Is MLET still a 'thing' now? If not is there a recommended process for loading Object, other than taking a .mlet type file and loading them by hand. Thanks -Pete From alanb at openjdk.org Mon Apr 10 13:55:43 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 10 Apr 2023 13:55:43 GMT Subject: jmx-dev RFR: 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries In-Reply-To: References: Message-ID: On Sat, 8 Apr 2023 01:11:08 GMT, Jiangli Zhou wrote: > Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries. src/java.management/share/native/libmanagement/management.c line 36: > 34: const JmmInterface* jmm_interface = NULL; > 35: JavaVM* jvm_management = NULL; > 36: jint jmm_version = 0; Is there any reason why these field can't be static? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13397#discussion_r1161738529 From jiangli at openjdk.org Mon Apr 10 19:22:50 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 10 Apr 2023 19:22:50 GMT Subject: jmx-dev RFR: 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries In-Reply-To: References:

Message-ID: On Mon, 10 Apr 2023 13:52:39 GMT, Alan Bateman wrote: >> Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries. > > src/java.management/share/native/libmanagement/management.c line 36: > >> 34: const JmmInterface* jmm_interface = NULL; >> 35: JavaVM* jvm_management = NULL; >> 36: jint jmm_version = 0; > > Is there any reason why these field can't be static? Thanks. My understanding is that 'static' gives internal linkage. The static variable is limited to the scope of the translate unit that declares it. It seems to be okay to use 'static' for the 'jvm' variables in [management.c](https://github.com/openjdk/jdk/pull/13397/files/0fa6a4b3984d91c124ee2adb9d6e1facdc63c156#diff-1717ac36c4bbefab688a4e75104417bec3687f78108096c2cca3af4ee552ab11) and [management_ext.c](https://github.com/openjdk/jdk/pull/13397/files#diff-0fa91a6686c9e5dc77bdef6981235785524108950075e58d2004853dc66e1977) to resolve the symbol issue. It's problematic for the usages in jdk.crypto.cryptoki code. I'll change management.c and management_ext.c to define 'jvm' as 'static' as suggested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13397#discussion_r1162008444 From jiangli at openjdk.org Mon Apr 10 19:38:18 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 10 Apr 2023 19:38:18 GMT Subject: jmx-dev RFR: 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries [v2] In-Reply-To: References: Message-ID: <1g3QgTxTpw20iuTgUcEWiuvXSiz6IwOv0BkO7zemPiY=.d5578ff1-eaa3-44c5-b08e-201e122d3c1d@github.com> > Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries. Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Update management.c and management_ext.c to define 'jvm' as static. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13397/files - new: https://git.openjdk.org/jdk/pull/13397/files/0fa6a4b3..40b1a82a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13397&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13397&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13397.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13397/head:pull/13397 PR: https://git.openjdk.org/jdk/pull/13397 From alanb at openjdk.org Tue Apr 11 11:07:33 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 11 Apr 2023 11:07:33 GMT Subject: jmx-dev RFR: 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries [v2] In-Reply-To: <1g3QgTxTpw20iuTgUcEWiuvXSiz6IwOv0BkO7zemPiY=.d5578ff1-eaa3-44c5-b08e-201e122d3c1d@github.com> References: <1g3QgTxTpw20iuTgUcEWiuvXSiz6IwOv0BkO7zemPiY=.d5578ff1-eaa3-44c5-b08e-201e122d3c1d@github.com> Message-ID: On Mon, 10 Apr 2023 19:38:18 GMT, Jiangli Zhou wrote: >> Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Update management.c and management_ext.c to define 'jvm' as static. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13397#pullrequestreview-1378993775 From kevinw at openjdk.org Tue Apr 11 14:12:36 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 11 Apr 2023 14:12:36 GMT Subject: jmx-dev RFR: 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries [v2] In-Reply-To: <1g3QgTxTpw20iuTgUcEWiuvXSiz6IwOv0BkO7zemPiY=.d5578ff1-eaa3-44c5-b08e-201e122d3c1d@github.com> References: <1g3QgTxTpw20iuTgUcEWiuvXSiz6IwOv0BkO7zemPiY=.d5578ff1-eaa3-44c5-b08e-201e122d3c1d@github.com> Message-ID: On Mon, 10 Apr 2023 19:38:18 GMT, Jiangli Zhou wrote: >> Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Update management.c and management_ext.c to define 'jvm' as static. Marked as reviewed by kevinw (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13397#pullrequestreview-1379355549 From jiangli at openjdk.org Tue Apr 11 15:08:48 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 11 Apr 2023 15:08:48 GMT Subject: jmx-dev RFR: 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries [v2] In-Reply-To: <1g3QgTxTpw20iuTgUcEWiuvXSiz6IwOv0BkO7zemPiY=.d5578ff1-eaa3-44c5-b08e-201e122d3c1d@github.com> References: <1g3QgTxTpw20iuTgUcEWiuvXSiz6IwOv0BkO7zemPiY=.d5578ff1-eaa3-44c5-b08e-201e122d3c1d@github.com> Message-ID: On Mon, 10 Apr 2023 19:38:18 GMT, Jiangli Zhou wrote: >> Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Update management.c and management_ext.c to define 'jvm' as static. Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13397#issuecomment-1503553861 From jiangli at openjdk.org Tue Apr 11 15:08:50 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 11 Apr 2023 15:08:50 GMT Subject: jmx-dev Integrated: 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries In-Reply-To: References: Message-ID: <-x_vxEhdcSWFLhsFY6_gPE15yQueMwboKZUAkuY42tM=.33bf748a-cc6e-4b25-ba27-80c2267b8c98@github.com> On Sat, 8 Apr 2023 01:11:08 GMT, Jiangli Zhou wrote: > Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries. This pull request has now been integrated. Changeset: ce4b9955 Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/ce4b9955568100d6b315336321ff8903b703f19e Stats: 34 lines in 5 files changed: 0 ins; 0 del; 34 mod 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries Reviewed-by: alanb, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/13397 From jiangli at openjdk.org Wed Apr 12 23:41:39 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 12 Apr 2023 23:41:39 GMT Subject: jmx-dev RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries Message-ID: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> Rename 'jmm_' to 'jmm__management_ext' in libmanagement_ext to resolve related linker errors when statically linking with both libmanagement and libmanagement_ext. ------------- Commit messages: - 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries Changes: https://git.openjdk.org/jdk/pull/13451/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13451&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305935 Stats: 28 lines in 7 files changed: 0 ins; 0 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/13451.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13451/head:pull/13451 PR: https://git.openjdk.org/jdk/pull/13451 From dholmes at openjdk.org Thu Apr 13 06:59:33 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 13 Apr 2023 06:59:33 GMT Subject: jmx-dev RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> Message-ID: On Wed, 12 Apr 2023 23:35:02 GMT, Jiangli Zhou wrote: > Rename 'jmm_' to 'jmm__management_ext' in libmanagement_ext to resolve related linker errors when statically linking with both libmanagement and libmanagement_ext. src/jdk.management/share/native/libmanagement_ext/management_ext.c line 36: > 34: const JmmInterface* jmm_interface_management_ext = NULL; > 35: static JavaVM* jvm = NULL; > 36: jint jmm_version_management_ext = 0; Is there not a way to stop these from being exported from the library, as I assume they are not actually intended for external use. ?? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1165084734 From jiangli at openjdk.org Thu Apr 13 20:07:32 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 13 Apr 2023 20:07:32 GMT Subject: jmx-dev RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> Message-ID: On Thu, 13 Apr 2023 06:56:46 GMT, David Holmes wrote: > Is there not a way to stop these from being exported from the library, as I assume they are not actually intended for external use. ?? Good question. We could make those as weak symbols as long as there is no concern about portability. In our current prototype on JDK 11, we use weak symbol to help detect if we are dealing with a statically linked binary at runtime then handle some of the cases conditionally (dynamic vs. static). Around the end of last year, I became aware that there could be issues in some cases on macos with weak symbols (e.g. without '-undefined dynamic_lookup'). I'm planning to look into alternatives (besides using weak symbol) when porting the support to the latest OpenJDK code base. Another approach is using 'objcopy' (https://web.mit.edu/gnu/doc/html/binutils_4.html) to localize the problematic symbols in the object file. It was suggested by our C++ colleague. We used that to hide symbols in libfreetype and libharfbuzz (there were problems when user code requires its own specific statically linked libfreetype and libharfbuzz due to versioning difference). So we first partially link all .o for the particular native library (in JDK) to form one .o file, then run 'objcopy' to localize the symbols. That hides the affected symbols during final link time. We had to do that since we don't control libfreetype and libharfbuzz. It worked for our specific case (for linux). It's probably not a general solution. The direct renaming in this case seems to be more strait forward. Any thoughts? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1165975548 From jiangli at openjdk.org Thu Apr 13 20:50:36 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 13 Apr 2023 20:50:36 GMT Subject: jmx-dev RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com>

Message-ID: On Thu, 13 Apr 2023 20:04:15 GMT, Jiangli Zhou wrote: >> src/jdk.management/share/native/libmanagement_ext/management_ext.c line 36: >> >>> 34: const JmmInterface* jmm_interface_management_ext = NULL; >>> 35: static JavaVM* jvm = NULL; >>> 36: jint jmm_version_management_ext = 0; >> >> Is there not a way to stop these from being exported from the library, as I assume they are not actually intended for external use. ?? > >> Is there not a way to stop these from being exported from the library, as I assume they are not actually intended for external use. ?? > > Good question. > > We could make those as weak symbols as long as there is no concern about portability. In our current prototype on JDK 11, we use weak symbol to help detect if we are dealing with a statically linked binary at runtime then handle some of the cases conditionally (dynamic vs. static). Around the end of last year, I became aware that there could be issues in some cases on macos with weak symbols (e.g. without '-undefined dynamic_lookup'). I'm planning to look into alternatives (besides using weak symbol) when porting the support to the latest OpenJDK code base. > > Another approach is using 'objcopy' (https://web.mit.edu/gnu/doc/html/binutils_4.html) to localize the problematic symbols in the object file. It was suggested by our C++ colleague. We used that to hide symbols in libfreetype and libharfbuzz (there were problems when user code requires its own specific statically linked libfreetype and libharfbuzz due to versioning difference). So we first partially link all .o for the particular native library (in JDK) to form one .o file, then run 'objcopy' to localize the symbols. That hides the affected symbols during final link time. We had to do that since we don't control libfreetype and libharfbuzz. It worked for our specific case (for linux). It's probably not a general solution. > > The direct renaming in this case seems to be more strait forward. Any thoughts? Forgot to mention that using 'static' effectively resolves the symbol issue when feasible, like the 'jvm' variable case. That doesn't work for the 'jmm_interface' and 'jmm_version' ... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1166010486 From dholmes at openjdk.org Thu Apr 13 23:10:32 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 13 Apr 2023 23:10:32 GMT Subject: jmx-dev RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com>

Message-ID: On Thu, 13 Apr 2023 20:47:39 GMT, Jiangli Zhou wrote: >>> Is there not a way to stop these from being exported from the library, as I assume they are not actually intended for external use. ?? >> >> Good question. >> >> We could make those as weak symbols as long as there is no concern about portability. In our current prototype on JDK 11, we use weak symbol to help detect if we are dealing with a statically linked binary at runtime then handle some of the cases conditionally (dynamic vs. static). Around the end of last year, I became aware that there could be issues in some cases on macos with weak symbols (e.g. without '-undefined dynamic_lookup'). I'm planning to look into alternatives (besides using weak symbol) when porting the support to the latest OpenJDK code base. >> >> Another approach is using 'objcopy' (https://web.mit.edu/gnu/doc/html/binutils_4.html) to localize the problematic symbols in the object file. It was suggested by our C++ colleague. We used that to hide symbols in libfreetype and libharfbuzz (there were problems when user code requires its own specific statically linked libfreetype and libharfbuzz due to versioning difference). So we first partially link all .o for the particular native library (in JDK) to form one .o file, then run 'objcopy' to localize the symbols. That hides the affected symbols during final link time. We had to do that since we don't control libfreetype and libharfbuzz. It worked for our specific case (for linux). It's probably not a general solution. >> >> The direct renaming in this case seems to be more strait forward. Any thoughts? > > Forgot to mention that using 'static' effectively resolves the symbol issue when feasible, like the 'jvm' variable case. That doesn't work for the 'jmm_interface' and 'jmm_version' ... I'm not familiar with the details of symbol scoping and linkage with libraries, but I would have hoped there was a way to have symbols like this shareable throughout the code that comprises the library without exposing them to users of the library. It used to be IIRC only functions we listed in the mapfiles were exposed, and these days we use explicit attributes to export them. Is there not some equivalent thing for data? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1166110590 From dholmes at openjdk.org Thu Apr 13 23:10:32 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 13 Apr 2023 23:10:32 GMT Subject: jmx-dev RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com>

Message-ID: On Thu, 13 Apr 2023 23:05:02 GMT, David Holmes wrote: >> Forgot to mention that using 'static' effectively resolves the symbol issue when feasible, like the 'jvm' variable case. That doesn't work for the 'jmm_interface' and 'jmm_version' ... > > I'm not familiar with the details of symbol scoping and linkage with libraries, but I would have hoped there was a way to have symbols like this shareable throughout the code that comprises the library without exposing them to users of the library. It used to be IIRC only functions we listed in the mapfiles were exposed, and these days we use explicit attributes to export them. Is there not some equivalent thing for data? > The direct renaming in this case seems to be more strait forward. If we were to do this then we should have a naming convention of some kind e.g. `_` but it strikes me as wrong as the code shouldn't need to know what library it is part of. In this case we do something as a simple point-fix, but to me it says there is a bigger problem. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1166111820 From jiangli at openjdk.org Fri Apr 14 00:36:42 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 14 Apr 2023 00:36:42 GMT Subject: jmx-dev RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com>

Message-ID: On Thu, 13 Apr 2023 23:07:23 GMT, David Holmes wrote: >> I'm not familiar with the details of symbol scoping and linkage with libraries, but I would have hoped there was a way to have symbols like this shareable throughout the code that comprises the library without exposing them to users of the library. It used to be IIRC only functions we listed in the mapfiles were exposed, and these days we use explicit attributes to export them. Is there not some equivalent thing for data? > >> The direct renaming in this case seems to be more strait forward. > > If we were to do this then we should have a naming convention of some kind e.g. `_` but it strikes me as wrong as the code shouldn't need to know what library it is part of. In this case we do something as a simple point-fix, but to me it says there is a bigger problem. > I'm not familiar with the details of symbol scoping and linkage with libraries, but I would have hoped there was a way to have symbols like this shareable throughout the code that comprises the library without exposing them to users of the library. It used to be IIRC only functions we listed in the mapfiles were exposed, and these days we use explicit attributes to export them. Is there not some equivalent thing for data? If my understanding is correct the mapfile is for exported symbols, which are in the export table. Those symbols can be dynamically looked up, e.g. via dlsym. By default, '-fvisibility=hidden' is used (https://github.com/openjdk/jdk/blob/master/make/common/modules/LibCommon.gmk#L41). The symbols are '.hidden' by default if not exported. E.g. jmm_interface is 'hidden' as objdump shows below. However, the linker error that we are seeing here for statically linking the libraries together is a different issue. The linker founds multiple ones in different object files, hence the failures. We'd have to change to use internal linkage for the affect variables to resolve the failure if feasible (without renaming). Please let me know if I'm missing anything. objdump: ./linux-x86_64-server-release/support/native/jdk.management/libmanagement_ext/management_ext.o: not a dynamic object SYMBOL TABLE: 0000000000000000 l df *ABS* 0000000000000000 management_ext.c ... 0000000000000000 g F .text 0000000000000068 JNI_OnLoad 0000000000000008 g O .bss 0000000000000008 .hidden jvm 0000000000000000 *UND* 0000000000000000 JVM_GetManagement 0000000000000010 g O .bss 0000000000000008 .hidden jmm_interface 0000000000000000 g O .bss 0000000000000004 .hidden jmm_version ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1166157315 From jiangli at openjdk.org Fri Apr 14 00:57:31 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 14 Apr 2023 00:57:31 GMT Subject: jmx-dev RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com>

Message-ID: On Fri, 14 Apr 2023 00:34:14 GMT, Jiangli Zhou wrote: >>> The direct renaming in this case seems to be more strait forward. >> >> If we were to do this then we should have a naming convention of some kind e.g. `_` but it strikes me as wrong as the code shouldn't need to know what library it is part of. In this case we do something as a simple point-fix, but to me it says there is a bigger problem. > >> I'm not familiar with the details of symbol scoping and linkage with libraries, but I would have hoped there was a way to have symbols like this shareable throughout the code that comprises the library without exposing them to users of the library. It used to be IIRC only functions we listed in the mapfiles were exposed, and these days we use explicit attributes to export them. Is there not some equivalent thing for data? > > If my understanding is correct the mapfile is for exported symbols, which are in the export table. Those symbols can be dynamically looked up, e.g. via dlsym. By default, '-fvisibility=hidden' is used (https://github.com/openjdk/jdk/blob/master/make/common/modules/LibCommon.gmk#L41). The symbols are '.hidden' by default if not exported. E.g. jmm_interface is 'hidden' as objdump shows below. However, the linker error that we are seeing here for statically linking the libraries together is a different issue. The linker founds multiple ones in different object files, hence the failures. We'd have to change to use internal linkage for the affect variables to resolve the failure if feasible (without renaming). Please let me know if I'm missing anything. > > objdump: ./linux-x86_64-server-release/support/native/jdk.management/libmanagement_ext/management_ext.o: not a dynamic object > SYMBOL TABLE: > 0000000000000000 l df *ABS* 0000000000000000 management_ext.c > ... > 0000000000000000 g F .text 0000000000000068 JNI_OnLoad > 0000000000000008 g O .bss 0000000000000008 .hidden jvm > 0000000000000000 *UND* 0000000000000000 JVM_GetManagement > 0000000000000010 g O .bss 0000000000000008 .hidden jmm_interface > 0000000000000000 g O .bss 0000000000000004 .hidden jmm_version > If we were to do this then we should have a naming convention of some kind e.g. `_` but it strikes me as wrong as the code shouldn't need to know what library it is part of. In this case we do something as a simple point-fix, but to me it says there is a bigger problem. Using a naming convention as you suggested sounds good. I'm not completely clear what's the bigger problem though. Could you please clarify? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1166165671 From jiangli at openjdk.org Fri Apr 14 02:12:33 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 14 Apr 2023 02:12:33 GMT Subject: jmx-dev RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com>

Message-ID: On Fri, 14 Apr 2023 00:54:22 GMT, Jiangli Zhou wrote: >>> I'm not familiar with the details of symbol scoping and linkage with libraries, but I would have hoped there was a way to have symbols like this shareable throughout the code that comprises the library without exposing them to users of the library. It used to be IIRC only functions we listed in the mapfiles were exposed, and these days we use explicit attributes to export them. Is there not some equivalent thing for data? >> >> If my understanding is correct the mapfile is for exported symbols, which are in the export table. Those symbols can be dynamically looked up, e.g. via dlsym. By default, '-fvisibility=hidden' is used (https://github.com/openjdk/jdk/blob/master/make/common/modules/LibCommon.gmk#L41). The symbols are '.hidden' by default if not exported. E.g. jmm_interface is 'hidden' as objdump shows below. However, the linker error that we are seeing here for statically linking the libraries together is a different issue. The linker founds multiple ones in different object files, hence the failures. We'd have to change to use internal linkage for the affect variables to resolve the failure if feasible (without renaming). Please let me know if I'm missing anything. >> >> objdump: ./linux-x86_64-server-release/support/native/jdk.management/libmanagement_ext/management_ext.o: not a dynamic object >> SYMBOL TABLE: >> 0000000000000000 l df *ABS* 0000000000000000 management_ext.c >> ... >> 0000000000000000 g F .text 0000000000000068 JNI_OnLoad >> 0000000000000008 g O .bss 0000000000000008 .hidden jvm >> 0000000000000000 *UND* 0000000000000000 JVM_GetManagement >> 0000000000000010 g O .bss 0000000000000008 .hidden jmm_interface >> 0000000000000000 g O .bss 0000000000000004 .hidden jmm_version > >> If we were to do this then we should have a naming convention of some kind e.g. `_` but it strikes me as wrong as the code shouldn't need to know what library it is part of. In this case we do something as a simple point-fix, but to me it says there is a bigger problem. > > Using a naming convention as you suggested sounds good. I'm not completely clear what's the bigger problem though. Could you please clarify? David, I was doing some more reading on the topic for our discussion in the thread and just found this: https://stackoverflow.com/questions/61663118/avoid-multiple-definition-linker-error-when-not-using-the-redefined-symbols. It has some good information on the symbol collision issue. It describes using 'objcopy' to localize or redefine symbols. It also mentions '--allow-multiple-definitions', which I didn't know before. However, '--allow-multiple-definitions' doesn't seem to be a good approach. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1166209365 From dholmes at openjdk.org Fri Apr 14 05:13:31 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 14 Apr 2023 05:13:31 GMT Subject: jmx-dev RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com>

Message-ID: On Fri, 14 Apr 2023 02:09:47 GMT, Jiangli Zhou wrote: >>> If we were to do this then we should have a naming convention of some kind e.g. `_` but it strikes me as wrong as the code shouldn't need to know what library it is part of. In this case we do something as a simple point-fix, but to me it says there is a bigger problem. >> >> Using a naming convention as you suggested sounds good. I'm not completely clear what's the bigger problem though. Could you please clarify? > > David, I was doing some more reading on the topic for our discussion in the thread and just found this: https://stackoverflow.com/questions/61663118/avoid-multiple-definition-linker-error-when-not-using-the-redefined-symbols. > > It has some good information on the symbol collision issue. It describes using 'objcopy' to localize or redefine symbols. It also mentions '--allow-multiple-definitions', which I didn't know before. However, '--allow-multiple-definitions' doesn't seem to be a good approach. Thanks for the pointer to stackoverflow - that made things a lot clearer. The symbol localization using `objcopy` seems to achieve what we desire but has the same drawback as renaming, that you need to know the symbols will clash to localize them. And it is also not ideal that changing the code may also need a change to the build file. :( With that in mind a simple renaming seems the least worst option for fixing this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1166283513 From dholmes at openjdk.org Fri Apr 14 05:23:33 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 14 Apr 2023 05:23:33 GMT Subject: jmx-dev RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> Message-ID: On Wed, 12 Apr 2023 23:35:02 GMT, Jiangli Zhou wrote: > Rename 'jmm_' to 'jmm__management_ext' in libmanagement_ext to resolve related linker errors when statically linking with both libmanagement and libmanagement_ext. One small request but otherwise okay. In wonder if @magicus or @erikj79 have anything to add from a build perspective? Thanks for the extended discussion on the potential options here. src/jdk.management/share/native/libmanagement_ext/management_ext.c line 34: > 32: #define ERR_MSG_SIZE 128 > 33: > 34: const JmmInterface* jmm_interface_management_ext = NULL; Can you add a comment before declaring the two "exported" symbols together: // These symbols are global in this library but need to be uniquely named to avoid conflicts // with same-named symbols in other libraries, when statically linking. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13451#pullrequestreview-1384611991 PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1166286584 From dholmes at openjdk.org Fri Apr 14 05:23:35 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 14 Apr 2023 05:23:35 GMT Subject: jmx-dev RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> Message-ID: On Fri, 14 Apr 2023 05:17:28 GMT, David Holmes wrote: >> Rename 'jmm_' to 'jmm__management_ext' in libmanagement_ext to resolve related linker errors when statically linking with both libmanagement and libmanagement_ext. > > src/jdk.management/share/native/libmanagement_ext/management_ext.c line 34: > >> 32: #define ERR_MSG_SIZE 128 >> 33: >> 34: const JmmInterface* jmm_interface_management_ext = NULL; > > Can you add a comment before declaring the two "exported" symbols together: > > // These symbols are global in this library but need to be uniquely named to avoid conflicts > // with same-named symbols in other libraries, when statically linking. > > Thanks. Oops! Sorry meant to add this comment to the declarations in the hpp file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1166288127 From jiangli at openjdk.org Fri Apr 14 17:16:24 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 14 Apr 2023 17:16:24 GMT Subject: jmx-dev RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries [v2] In-Reply-To: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> Message-ID: > Rename 'jmm_' to 'jmm__management_ext' in libmanagement_ext to resolve related linker errors when statically linking with both libmanagement and libmanagement_ext. Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Add comment suggested by dholmes-ora. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13451/files - new: https://git.openjdk.org/jdk/pull/13451/files/f10e1a06..9d98f728 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13451&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13451&range=00-01 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13451.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13451/head:pull/13451 PR: https://git.openjdk.org/jdk/pull/13451 From jiangli at openjdk.org Fri Apr 14 17:16:28 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 14 Apr 2023 17:16:28 GMT Subject: jmx-dev RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries [v2] In-Reply-To: References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com>

Message-ID: <-F0EefG2_UQGSMBo2k-FLfQKXE100586ZgtGGTjcVVQ=.d49dfc8a-58bd-471f-8f67-e14fce048125@github.com> On Fri, 14 Apr 2023 05:20:48 GMT, David Holmes wrote: >> src/jdk.management/share/native/libmanagement_ext/management_ext.c line 34: >> >>> 32: #define ERR_MSG_SIZE 128 >>> 33: >>> 34: const JmmInterface* jmm_interface_management_ext = NULL; >> >> Can you add a comment before declaring the two "exported" symbols together: >> >> // These symbols are global in this library but need to be uniquely named to avoid conflicts >> // with same-named symbols in other libraries, when statically linking. >> >> Thanks. > > Oops! Sorry meant to add this comment to the declarations in the hpp file. Added comment as suggested (with minor adjustment) in management_ext.h. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1167098349 From jiangli at openjdk.org Fri Apr 14 17:16:26 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 14 Apr 2023 17:16:26 GMT Subject: jmx-dev RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> Message-ID: On Wed, 12 Apr 2023 23:35:02 GMT, Jiangli Zhou wrote: > Rename 'jmm_' to 'jmm__management_ext' in libmanagement_ext to resolve related linker errors when statically linking with both libmanagement and libmanagement_ext. Thanks for the review and discussion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13451#issuecomment-1508978901 From jiangli at openjdk.org Fri Apr 14 21:16:40 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 14 Apr 2023 21:16:40 GMT Subject: jmx-dev Integrated: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> Message-ID: On Wed, 12 Apr 2023 23:35:02 GMT, Jiangli Zhou wrote: > Rename 'jmm_' to 'jmm__management_ext' in libmanagement_ext to resolve related linker errors when statically linking with both libmanagement and libmanagement_ext. This pull request has now been integrated. Changeset: 314bad36 Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/314bad36135c6404b31a41efc48954cb5b7877fd Stats: 31 lines in 7 files changed: 3 ins; 0 del; 28 mod 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/13451 From jiangli at openjdk.org Mon Apr 17 17:25:16 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 17 Apr 2023 17:25:16 GMT Subject: jmx-dev RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries Message-ID: - Make functions 'static' when feasible: - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c. - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c. - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c. - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static. - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static. - Rename functions by following the existing naming usages in different libraries code: - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss. - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11. - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11. - Rename throwIOException() to p11ThrowIOException() in libj2pks11. - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw functions. - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used. - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c. ------------- Commit messages: - - Fix whitespaces in p11_util.c. - 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries Changes: https://git.openjdk.org/jdk/pull/13497/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13497&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306033 Stats: 162 lines in 25 files changed: 17 ins; 28 del; 117 mod Patch: https://git.openjdk.org/jdk/pull/13497.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13497/head:pull/13497 PR: https://git.openjdk.org/jdk/pull/13497 From jpai at openjdk.org Tue Apr 18 06:06:42 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 18 Apr 2023 06:06:42 GMT Subject: jmx-dev RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries In-Reply-To: References: Message-ID: On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou wrote: > - Make functions 'static' when feasible: > - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. > - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c. > - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c. > - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c. > - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static. > - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static. > > - Rename functions by following the existing naming usages in different libraries code: > - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss. > - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11. > - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11. > - Rename throwIOException() to p11ThrowIOException() in libj2pks11. > - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw functions. > > - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used. > - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c. Hello Jiangli, I have no experience in C language or the symbol linking that's involved in this PR, but given similar PRs that have been merged recently, is there some way these issues can be caught when code changes are being reviewed in future? Or would this require explicit run of some tool to identify these issues? I realize that you have been working on JDK-8303796 which proposes to build statically linked JDK image. Once that work is done and integrated in the JDK build, would that catch issues like these across different components of the JDK, before such changes get merged in? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1512486343 From jiangli at openjdk.org Tue Apr 18 17:52:51 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 18 Apr 2023 17:52:51 GMT Subject: jmx-dev RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries In-Reply-To: References: Message-ID: On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou wrote: > - Make functions 'static' when feasible: > - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. > - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c. > - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c. > - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c. > - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static. > - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static. > > - Rename functions by following the existing naming usages in different libraries code: > - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss. > - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11. > - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11. > - Rename throwIOException() to p11ThrowIOException() in libj2pks11. > - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw functions. > > - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used. > - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c. Hi Jaikiran, Thanks for looking into this. > is there some way these issues can be caught when code changes are being reviewed in future? Or would this require explicit run of some tool to identify these issues? The symbol issues are reported as linker errors when statically linking the executable with JDK native libraries and libjvm. I just created a branch with the preliminary makefile changes for optionally statically linking JDK, which can be used to demonstrate/identify the issues: https://github.com/jianglizhou/jdk/pull/new/JDK-8303796 The branch is based on our prototype on JDK 11, but mostly reworked. It re-uses the existing JDK make infrastructure based on the feedback from Severin Gehwolf in https://bugs.openjdk.org/browse/JDK-8303796. Still need to clean up the makefile changes before making it ready for review. Early feedback/input is also welcomed. > Once that work is done and integrated in the JDK build, would that catch issues like these across different components of the JDK, before such changes get merged in? Yes, one option would be to include the JDK static build in pre-submit testing, which can catch any changes breaking the build. That would need to be discussed broadly with other members in OpenJDK. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1513574228 From jpai at openjdk.org Wed Apr 19 11:03:42 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 19 Apr 2023 11:03:42 GMT Subject: jmx-dev RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries In-Reply-To: References: Message-ID: On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou wrote: > - Make functions 'static' when feasible: > - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. > - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c. > - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c. > - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c. > - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static. > - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static. > > - Rename functions by following the existing naming usages in different libraries code: > - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss. > - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11. > - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11. > - Rename throwIOException() to p11ThrowIOException() in libj2pks11. > - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw functions. > > - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used. > - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c. Thank you for those details, Jiangli. > > > > Once that work is done and integrated in the JDK build, would that catch issues like these across different components of the JDK, before such changes get merged in? > > Yes, one option would be to include the JDK static build in pre-submit testing, which can catch any changes breaking the build. That would need to be discussed broadly with other members in OpenJDK. Even if it doesn't get enrolled in the pre-submit testing, I think the fact that there will be a build within the JDK which can catch these issues is a good thing. It might catch the issue(s) after the integration, but I think it's still a good improvement to have these issues identified by running a specific variant of the JDK build process. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1514538152 From jiangli at openjdk.org Wed Apr 19 15:18:44 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 19 Apr 2023 15:18:44 GMT Subject: jmx-dev RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries In-Reply-To: References:

Message-ID: On Wed, 19 Apr 2023 11:01:07 GMT, Jaikiran Pai wrote: > Even if it doesn't get enrolled in the pre-submit testing, I think the fact that there will be a build within the JDK which can catch these issues is a good thing. It might catch the issue(s) after the integration, but I think it's still a good improvement to have these issues identified by running a specific variant of the JDK build process. Agreed, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1514918976 From jiangli at openjdk.org Mon Apr 24 17:27:44 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 24 Apr 2023 17:27:44 GMT Subject: jmx-dev RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries In-Reply-To: References: Message-ID: On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou wrote: > - Make functions 'static' when feasible: > - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. > - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c. > - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c. > - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c. > - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static. > - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static. > > - Rename functions by following the existing naming usages in different libraries code: > - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss. > - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11. > - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11. > - Rename throwIOException() to p11ThrowIOException() in libj2pks11. > - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw functions. > > - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used. > - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c. Gentle ping, please help review this PR. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1520559203 From mpowers at openjdk.org Mon Apr 24 22:45:13 2023 From: mpowers at openjdk.org (Mark Powers) Date: Mon, 24 Apr 2023 22:45:13 GMT Subject: jmx-dev RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries In-Reply-To: References: Message-ID: On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou wrote: > - Make functions 'static' when feasible: > - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. > - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c. > - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c. > - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c. > - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static. > - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static. > > - Rename functions by following the existing naming usages in different libraries code: > - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss. > - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11. > - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11. > - Rename throwIOException() to p11ThrowIOException() in libj2pks11. > - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw functions. > > - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used. > - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c. Update copyrights to 2023. src/java.security.jgss/share/native/libj2gss/GSSLibStub.c line 201: > 199: cb = malloc(sizeof(struct gss_channel_bindings_struct)); > 200: if (cb == NULL) { > 201: gssThrowOutOfMemoryError(env,NULL); While you're fixing this, add a space between arguments, e.g. `(env,NULL) `becomes `(env, NULL)`. src/java.security.jgss/share/native/libj2gss/NativeUtil.c line 456: > 454: > 455: /* Throws a Java Exception by name */ > 456: static void throwByName(JNIEnv *env, const char *name, const char *msg) { Why can't you move the few lines of `throwByName()` into `gssThrowOutOfMemoryError()` and totally remove `throwByName()`? ------------- PR Review: https://git.openjdk.org/jdk/pull/13497#pullrequestreview-1398895019 PR Review Comment: https://git.openjdk.org/jdk/pull/13497#discussion_r1175839776 PR Review Comment: https://git.openjdk.org/jdk/pull/13497#discussion_r1175840162 From jiangli at openjdk.org Tue Apr 25 00:47:17 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 25 Apr 2023 00:47:17 GMT Subject: jmx-dev RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries [v2] In-Reply-To: References: Message-ID: > - Make functions 'static' when feasible: > - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. > - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c. > - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c. > - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c. > - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static. > - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static. > > - Rename functions by following the existing naming usages in different libraries code: > - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss. > - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11. > - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11. > - Rename throwIOException() to p11ThrowIOException() in libj2pks11. > - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw functions. > > - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used. > - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c. Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Minor updates, as suggested by mcpowers: - Update copyright headers in affected files. - Formatting update in src/java.security.jgss/share/native/libj2gss/GSSLibStub.c. - Remove throwByName() and move the logic into gssThrowOutOfMemoryError() (the only caller) in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13497/files - new: https://git.openjdk.org/jdk/pull/13497/files/9d319df6..fcb35192 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13497&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13497&range=00-01 Stats: 35 lines in 25 files changed: 0 ins; 6 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/13497.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13497/head:pull/13497 PR: https://git.openjdk.org/jdk/pull/13497 From jiangli at openjdk.org Tue Apr 25 00:47:20 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 25 Apr 2023 00:47:20 GMT Subject: jmx-dev RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries [v2] In-Reply-To: References:

Message-ID: <4ezRtZpp6IfNoO_w2nyu2FA9GAy5k8FUrppmfd0pCqQ=.36ad7365-ae7f-40af-b0ff-86f1cfc60175@github.com> On Mon, 24 Apr 2023 22:41:53 GMT, Mark Powers wrote: > Update copyrights to 2023. Done, thanks. > src/java.security.jgss/share/native/libj2gss/GSSLibStub.c line 201: > >> 199: cb = malloc(sizeof(struct gss_channel_bindings_struct)); >> 200: if (cb == NULL) { >> 201: gssThrowOutOfMemoryError(env,NULL); > > While you're fixing this, add a space between arguments, e.g. `(env,NULL) `becomes `(env, NULL)`. Done, thanks. > src/java.security.jgss/share/native/libj2gss/NativeUtil.c line 456: > >> 454: >> 455: /* Throws a Java Exception by name */ >> 456: static void throwByName(JNIEnv *env, const char *name, const char *msg) { > > Why can't you move the few lines of `throwByName()` into `gssThrowOutOfMemoryError()` and totally remove `throwByName()`? Updated as suggested, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1521007212 PR Review Comment: https://git.openjdk.org/jdk/pull/13497#discussion_r1175910048 PR Review Comment: https://git.openjdk.org/jdk/pull/13497#discussion_r1175910110 From mark.powers at oracle.com Mon Apr 24 22:01:38 2023 From: mark.powers at oracle.com (Mark Powers) Date: Mon, 24 Apr 2023 22:01:38 +0000 Subject: jmx-dev RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries In-Reply-To: References:

Message-ID: I'll take a look. ________________________________ From: security-dev on behalf of Jiangli Zhou Sent: Monday, April 24, 2023 10:27 AM To: jmx-dev at openjdk.org ; security-dev at openjdk.org ; serviceability-dev at openjdk.org Subject: Re: RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou wrote: > - Make functions 'static' when feasible: > - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. > - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c. > - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c. > - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c. > - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static. > - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static. > > - Rename functions by following the existing naming usages in different libraries code: > - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss. > - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11. > - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11. > - Rename throwIOException() to p11ThrowIOException() in libj2pks11. > - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw functions. > > - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used. > - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c. Gentle ping, please help review this PR. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1520559203 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.org Wed Apr 26 11:22:23 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 26 Apr 2023 11:22:23 GMT Subject: jmx-dev RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries [v2] In-Reply-To: References:

Message-ID: On Tue, 25 Apr 2023 00:47:17 GMT, Jiangli Zhou wrote: >> - Make functions 'static' when feasible: >> - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. >> - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c. >> - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c. >> - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c. >> - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static. >> - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static. >> >> - Rename functions by following the existing naming usages in different libraries code: >> - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss. >> - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11. >> - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11. >> - Rename throwIOException() to p11ThrowIOException() in libj2pks11. >> - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw functions. >> >> - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used. >> - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Minor updates, as suggested by mcpowers: > - Update copyright headers in affected files. > - Formatting update in src/java.security.jgss/share/native/libj2gss/GSSLibStub.c. > - Remove throwByName() and move the logic into gssThrowOutOfMemoryError() (the only caller) in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1523566931 From jiangli at openjdk.org Wed Apr 26 16:16:02 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 26 Apr 2023 16:16:02 GMT Subject: jmx-dev Integrated: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries In-Reply-To: References: Message-ID: On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou wrote: > - Make functions 'static' when feasible: > - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. > - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c. > - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c. > - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c. > - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static. > - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static. > > - Rename functions by following the existing naming usages in different libraries code: > - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss. > - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11. > - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11. > - Rename throwIOException() to p11ThrowIOException() in libj2pks11. > - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw functions. > > - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used. > - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c. This pull request has now been integrated. Changeset: 9bc6a212 Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/9bc6a212f70eede108a8d3bc1ba1f780722b6e33 Stats: 194 lines in 25 files changed: 17 ins; 34 del; 143 mod 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/13497