Integrated: JDK-8320005 : Allow loading of shared objects with .a extension on AIX
On Fri, 10 Nov 2023 12:28:46 GMT, Suchismith Roy wrote: > J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. This pull request has now been integrated. Changeset: e85355ad Author:Suchismith Roy Committer: Martin Doerr URL: https://git.openjdk.org/jdk/commit/e85355ada4ac1061c49ee9f1247d37a437c7b5ab Stats: 22 lines in 1 file changed: 20 ins; 1 del; 1 mod 8320005: Allow loading of shared objects with .a extension on AIX Reviewed-by: amitkumar, stuefe, jkern, mdoerr - PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v27]
On Tue, 27 Feb 2024 08:23:58 GMT, Suchismith Roy wrote:
>> src/hotspot/os/aix/os_aix.cpp line 1176:
>>
>>> 1174: if (result == nullptr && pointer_to_dot != nullptr &&
>>> strcmp(pointer_to_dot, old_extension) == 0) {
>>> 1175: snprintf(pointer_to_dot, sizeof(old_extension), "%s",
>>> new_extension);
>>> 1176: result = dll_load_library(file_path, ebuf, ebuflen);
>>
>> You should have adapted the indentation, too.
>
> Which indentation ?
oh! to reduce the spaces
-
PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1503821531
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v27]
On Tue, 27 Feb 2024 08:22:21 GMT, Martin Doerr wrote:
>> Suchismith Roy has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>>remove redundant logic
>
> src/hotspot/os/aix/os_aix.cpp line 1176:
>
>> 1174: if (result == nullptr && pointer_to_dot != nullptr &&
>> strcmp(pointer_to_dot, old_extension) == 0) {
>> 1175: snprintf(pointer_to_dot, sizeof(old_extension), "%s",
>> new_extension);
>> 1176: result = dll_load_library(file_path, ebuf, ebuflen);
>
> You should have adapted the indentation, too.
Which indentation ?
@TheRealMDoerr adapted
-
PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1503820212
PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1503824233
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v28]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: indendt - Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/57914589..55090448 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16604=27 - incr: https://webrevs.openjdk.org/?repo=jdk=16604=26-27 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v27]
On Tue, 27 Feb 2024 07:48:00 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared >> library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load >> fails.It fails to identify the shared library ibm_16_am.a shared archive >> file on AIX. >> Hence we are providing a function which will additionally search for .a file >> on AIX ,when the search for .so file fails. > > Suchismith Roy has updated the pull request incrementally with one additional > commit since the last revision: > >remove redundant logic Thank you everyone for your inputs, It was great learning from all of them. I understood about secure coding guidelines in practice, which was a great experience. - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1965971937
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v27]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: remove redundant logic - Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/1943445d..57914589 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16604=26 - incr: https://webrevs.openjdk.org/?repo=jdk=16604=25-26 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v25]
On Sun, 25 Feb 2024 06:32:20 GMT, Thomas Stuefe wrote: >> Suchismith Roy has updated the pull request incrementally with one >> additional commit since the last revision: >> >>remove space > > src/hotspot/os/aix/os_aix.cpp line 1173: > >> 1171: char* const pointer_to_dot = strrchr(file_path, '.'); >> 1172: char const *old_extension = ".so"; >> 1173: char const *new_extension = ".a"; > > Suggestion: > > char* const file_path = strdup(filename); > char* const pointer_to_dot = strrchr(file_path, '.'); > const char old_extension[] = ".so"; > const char new_extension[] = ".a"; > STATIC_ASSERT(sizeof(old_exception) >= sizeof(new_exception)); > > and remove runtime-assert below @tstuefe done. Anyreason why we use [] instead of the pointer. Doesn't [] convert into *(baseaddress) ? - PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1502454196
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v26]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: Address review comments - Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/664e41a4..1943445d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16604=25 - incr: https://webrevs.openjdk.org/?repo=jdk=16604=24-25 Stats: 18 lines in 1 file changed: 0 ins; 10 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v25]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: remove space - Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/c6b3deb3..664e41a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16604=24 - incr: https://webrevs.openjdk.org/?repo=jdk=16604=23-24 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v23]
On Mon, 19 Feb 2024 17:16:53 GMT, Suchismith Roy wrote: >> Argh, I keep forgetting `dlopen` does not set errno (at least its not >> guaranteed by the standard). >> >> Ok, in this case, I would not analyze the string either because it may be >> locale-dependent. >> >> Never mind then; I'd thought this would be easy. One could probably use >> load() instead of dlopen() on AIX, but that change would require more >> investigations to see if load() and dlopen() are equivalent. >> >> Okay, in that case just skip the errno test and call the second dlopen >> directly. Lets hope for the best then. > > Sure .thank for all the info. This is great learning. reverted the error code handling. - PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1495450839
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v23]
On Mon, 19 Feb 2024 13:55:58 GMT, Thomas Stuefe wrote: >> In this special case here I would not use errno, but the string returned in >> ebuf, in case the result is nullptr. > > Argh, I keep forgetting `dlopen` does not set errno (at least its not > guaranteed by the standard). > > Ok, in this case, I would not analyze the string either because it may be > locale-dependent. > > Never mind then; I'd thought this would be easy. One could probably use > load() instead of dlopen() on AIX, but that change would require more > investigations to see if load() and dlopen() are equivalent. > > Okay, in that case just skip the errno test and call the second dlopen > directly. Lets hope for the best then. Sure .thank for all the info. This is great learning. - PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1494859583
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v24]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision: - remove error_code - revert error code check - Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/f5693f47..c6b3deb3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16604=23 - incr: https://webrevs.openjdk.org/?repo=jdk=16604=22-23 Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v23]
On Mon, 19 Feb 2024 12:15:22 GMT, Joachim Kern wrote: >>> this might not necessarily be the `errno` of the underlying `dlopen()`, >>> because there is to much code in-between and branches without a `dlopen()` >>> call. >> >> As i see the code in Aix_dlopen , there is no additional functional call >> after the dlopen which might change the errno . Could you tell me the how >> the errno would get overriden ? > > Suchi, errno is a global static variable. If some runtime API sets it, it > will continue to have this value until the next runtime call updates it. If > you call dll_load_library, there are many execution paths not passing > dlopen(). So you receive an errno from some unknown runtime API called > before. The correct errno handling is: > > errno = 0; > runtime_API_which_might_set_errno_in_error_case(); > error_code = errno; > > But what you really need is the result of the `search_file_in_LIBPATH(...)` > call in `Aix_dlopen()`. If it is false, then the error_report starts with the > string "Could not load module . ." > This is called in any case. A `dlopen()` is not called in any case. Thanks for the detailed explanation @JoKern65 . Do then in this errno check may not be necessary ? or can we still set errno and access it some way ? - PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1494516185
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v23]
On Mon, 19 Feb 2024 10:15:59 GMT, Martin Doerr wrote:
>> Suchismith Roy has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address review comments
>
> src/hotspot/os/aix/os_aix.cpp line 1185:
>
>> 1183: // Shared object in .so format dont have braces, hence they get
>> removed for archives with members.
>> 1184: if (error_code == EACCES || error_code == ENOENT) {
>> 1185: if (strlen(new_extension) > strlen(old_extension)){
>
> I think this should better be an assertion because the extensions are
> constants.
As assertions are not supported in debug builds i did not use assert. May i
know what is the purpose of assert,in general, as per design ?
-
PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1494392043
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v23]
On Mon, 19 Feb 2024 10:42:03 GMT, Joachim Kern wrote: > this might not necessarily be the `errno` of the underlying `dlopen()`, > because there is to much code in-between and branches without a `dlopen()` > call. As i see the code in Aix_dlopen , there is no additional functional call after the dlopen which might change the errno . Could you tell me the how the errno would get overriden ? - PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1494389934
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v22]
On Fri, 16 Feb 2024 12:50:37 GMT, Thomas Stuefe wrote: > * Please assert that the replacement string is smaller than the original > string (which it should be, *.so is longer than *.a, but this is insurance > against anyone changing the code in the future) I have done it now. This is just to make the developer aware that this was the design decision taken ? @tstuefe - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1952105754
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v23]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: Address review comments - Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/c6332f67..f5693f47 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16604=22 - incr: https://webrevs.openjdk.org/?repo=jdk=16604=21-22 Stats: 16 lines in 1 file changed: 8 ins; 3 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v22]
On Fri, 16 Feb 2024 05:25:44 GMT, Thomas Stuefe wrote: > > > Hi, > > > some remarks: > > > > > > * there is no need for a copy for the first call to dll_load_library. > > > Just hand in the string 1:1. > > > * I would only do the *.a fallback loading if the error indicates that > > > the *.so file had not been there. So, only if EACCESS or ENOENT; in all > > > other cases I would not do the fallback. E.g. if the *.so file cannot be > > > loaded due to a header mismatch. See > > > https://www.ibm.com/docs/en/aix/7.1?topic=l-load-loadandinit-subroutines > > > * Please use os::strdup. > > > * Please assert that the replacement string is smaller than the original > > > string (which it should be, *.so is longer than *.a, but this is > > > insurance against anyone changing the code in the future) > > > > > > Thank you, Thomas > > > > > > Sure working on them. May i know why we are using the load routine in the > > 2nd point ? . Currently we do a *.a fallback only when dlopen fails. Does > > load function save some steps here ? > > I don't understand the question, sorry. > > What I mean is when the first dlopen fails AND its error indicates the shared > library had been missing, only then attempt the *.a fallback. I see. I think i was referred to the init routine in the link. So you mean based on the errors inside dll_load_library, we set the errno to appropriate Error and then check for that before using the fallback , is that correct ? - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1948295997
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v22]
On Thu, 15 Feb 2024 08:15:16 GMT, Thomas Stuefe wrote: > Hi, > > some remarks: > > * there is no need for a copy for the first call to dll_load_library. Just > hand in the string 1:1. > * I would only do the *.a fallback loading if the error indicates that the > *.so file had not been there. So, only if EACCESS or ENOENT; in all other > cases I would not do the fallback. E.g. if the *.so file cannot be loaded due > to a header mismatch. See > https://www.ibm.com/docs/en/aix/7.1?topic=l-load-loadandinit-subroutines > * Please use os::strdup. > * Please assert that the replacement string is smaller than the original > string (which it should be, *.so is longer than *.a, but this is insurance > against anyone changing the code in the future) > > Thank you, Thomas Sure working on them. May i know why we are using the load routine in the 2nd point ? . Currently we do a *.a fallback only when dlopen fails. Does load function save some steps here ? - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1946756694
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v14]
On Mon, 12 Feb 2024 17:21:55 GMT, Suchismith Roy wrote: > > > > The trailing whitespace errors must get fixed (integration blocker). > > > > > > > > > I am unable to resolve this. The spaces seem fine as i see it in the > > > terminal. Could it be some other error ? > > > > > > Strange. I don't see any whitespace problem, either. Maybe it's possible to > > rerun jcheck (GitHub Actions). Otherwise, you may need to create a new PR. > > Re running tests is not helping as i made more commits. Not sure why it > arrived all of a sudden. I have resolved this, I reverted back to old commit where assert was present. Then brought it back to current state. Saw that there was one line with some trailing whitespaces, using sed command with valid regex. But the jcheck was pointing at the wrong line , which was confusing. - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1939268192
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v22]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: Remove not matched trailing whitespaces - Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/d887ad73..c6332f67 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16604=21 - incr: https://webrevs.openjdk.org/?repo=jdk=16604=20-21 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v21]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: revert log_info - Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/ecf8ad6c..d887ad73 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16604=20 - incr: https://webrevs.openjdk.org/?repo=jdk=16604=19-20 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v20]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: revert - Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/b5cf57d6..ecf8ad6c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16604=19 - incr: https://webrevs.openjdk.org/?repo=jdk=16604=18-19 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v19]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: Check to revert commit and do jcheck - Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/ca75a337..b5cf57d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16604=18 - incr: https://webrevs.openjdk.org/?repo=jdk=16604=17-18 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v14]
On Thu, 8 Feb 2024 14:39:24 GMT, Martin Doerr wrote: > > > The trailing whitespace errors must get fixed (integration blocker). > > > > > > I am unable to resolve this. The spaces seem fine as i see it in the > > terminal. Could it be some other error ? > > Strange. I don't see any whitespace problem, either. Maybe it's possible to > rerun jcheck (GitHub Actions). Otherwise, you may need to create a new PR. Re running tests is not helping as i made more commits. Not sure why it arrived all of a sudden. - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1939190557
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v18]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: update comment - Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/f4b85357..ca75a337 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16604=17 - incr: https://webrevs.openjdk.org/?repo=jdk=16604=16-17 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v15]
On Thu, 8 Feb 2024 10:46:37 GMT, Joachim Kern wrote: > > > > > May be this is academical: Your code works for plain libraries > > > > > replacing the .so extension by .a. Suppose the case the goal is to > > > > > load a member of an archive libname.a(member.o), but as in the plain > > > > > case you get as input libname.so(member.o). In this case you will cut > > > > > of the member producing the resulting string libname.a instead of > > > > > libname.a(member.o). Should this situation also be handled or is this > > > > > forbidden? > > > > > > > > > > > > Hi Joachim I think the case for member archives exists in dl_open. It > > > > checks for braces and sets the RTLD_MEMBER flag. (Lines 1132-1134) > > > > > > > > > Hi Suchi, but **before** you call dll_load_library, you remove the member > > > part in my mentioned case > > > > > > Do we have a case where a .so files has braces mentioning the archive > > members ? I think not. > > That's why I am asking. If not this is an academical concern. But it should > be mentioned in a comment, that this is not expected to work. Yes, but i was also asking if at all there is a case ,which i am not aware of. Sure i will mention it in comments. But there is one case that keep me thinking, is that ..will a particular .so file have an .a file with same name, but also referred to a member ? - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1933833986
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v15]
On Thu, 8 Feb 2024 10:30:43 GMT, Joachim Kern wrote: > > > May be this is academical: Your code works for plain libraries replacing > > > the .so extension by .a. Suppose the case the goal is to load a member of > > > an archive libname.a(member.o), but as in the plain case you get as input > > > libname.so(member.o). In this case you will cut of the member producing > > > the resulting string libname.a instead of libname.a(member.o). Should > > > this situation also be handled or is this forbidden? > > > > > > Hi Joachim I think the case for member archives exists in dl_open. It > > checks for braces and sets the RTLD_MEMBER flag. (Lines 1132-1134) > > Hi Suchi, but **before** you call dll_load_library, you remove the member > part in my mentioned case Do we have a case where a .so files has braces mentioning the archive members ? I think not. - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1933795230
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v14]
On Mon, 5 Feb 2024 09:01:38 GMT, Martin Doerr wrote: > The trailing whitespace errors must get fixed (integration blocker). I am unable to resolve this. The spaces seem fine as i see it in the terminal. Could it be some other error ? - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1933774774
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v15]
On Tue, 6 Feb 2024 10:26:36 GMT, Joachim Kern wrote: > May be this is academical: Your code works for plain libraries replacing the > .so extension by .a. Suppose the case the goal is to load a member of an > archive libname.a(member.o), but as in the plain case you get as input > libname.so(member.o). In this case you will cut of the member producing the > resulting string libname.a instead of libname.a(member.o). Should this > situation also be handled or is this forbidden? Hi Joachim I think the case for member archives exists in dl_open. It checks for braces and sets the RTLD_MEMBER flag. (Lines 1132-1134) - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1933769585
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v17]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision: - spaces and comma - debug lines - remove debug lines - Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/0503ed8f..f4b85357 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16604=16 - incr: https://webrevs.openjdk.org/?repo=jdk=16604=15-16 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v16]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: Free the buffer - Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/14e0ed39..0503ed8f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16604=15 - incr: https://webrevs.openjdk.org/?repo=jdk=16604=14-15 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v15]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: change control flow - Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/f4c1788b..14e0ed39 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16604=14 - incr: https://webrevs.openjdk.org/?repo=jdk=16604=13-14 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v14]
On Mon, 5 Feb 2024 09:01:06 GMT, Martin Doerr wrote:
>> Suchismith Roy has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Change logging
>
> src/hotspot/os/aix/os_aix.cpp line 1183:
>
>> 1181: // If the load fails,we try to reload by changing the extension to
>> .a for .so files only.
>> 1182: if (result == nullptr) {
>> 1183: if (strcmp(pointer_to_dot, ".so") == 0) {
>
> We could possibly reach here with `pointer_to_dot` == nullptr. Invoking
> strcmp causes undefined behavior!
Yes. Do we exit when there is no extension in the file ..or we can just append
an extension manually and let the program flow go through.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1477884033
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v14]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: Change logging - Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/af761abb..f4c1788b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16604=13 - incr: https://webrevs.openjdk.org/?repo=jdk=16604=12-13 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v13]
On Thu, 1 Feb 2024 04:17:41 GMT, Martin Doerr wrote: >> An assertion is only used for debug builds. Such an error should be handled >> in product builds as well. I think an attempt to load an invalid library >> should simply fail. You may add logging if needed. >> @tstuefe: Do you agree or have another proposal to handle such errors? > > In addition, the nullptr check is important to avoid undefined behavior when > passing `pointer_to_dot` to any string function. Ok. So then may be we can return a nullptr and do a log_info(os) with the correct error report ? @tstuefe @TheRealMDoerr - PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1474128334
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v13]
On Wed, 31 Jan 2024 13:20:52 GMT, Martin Doerr wrote: >> Suchismith Roy has updated the pull request incrementally with one >> additional commit since the last revision: >> >> spelling > > src/hotspot/os/aix/os_aix.cpp line 1176: > >> 1174: strncpy(file_path,filename, buffer_length + 1); >> 1175: char* const pointer_to_dot = strrchr(file_path, '.'); >> 1176: assert(pointer_to_dot != nullptr, "Attempting to load a shared >> object without extension? %s", filename); > > This should not only be an assertion. I think the check could be used instead > of the strcmp below. I didn't follow that. You mean i need to keep a check if it is null and print it out ? - PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1472963709
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v13]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: spelling - Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/713e514b..af761abb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16604=12 - incr: https://webrevs.openjdk.org/?repo=jdk=16604=11-12 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v12]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: Clarify comment - Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/257f5def..713e514b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16604=11 - incr: https://webrevs.openjdk.org/?repo=jdk=16604=10-11 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v11]
On Mon, 29 Jan 2024 09:48:40 GMT, Joachim Kern wrote: >> Suchismith Roy has updated the pull request incrementally with one >> additional commit since the last revision: >> >> update comment > > src/hotspot/os/aix/os_aix.cpp line 1166: > >> 1164: Search order: >> 1165: libfilename-> load "libfilename.so" first,then load libfilename.a,on >> failure. >> 1166: In,OpenJ9,the libary with .so extension is loaded first and then .a >> extension,on failure. > > Hi Suchi, I'm puzzled. Your comment implies for me, that load library gets a > 'base' filename without 'lib' prefix and without extension (e.g. 'name'). > Then the j9 code creates the filename 'libname.so' first and on failure > 'libname.a' second. What about given libname.so explicitly (e.g. libname.so)? > Does j9 really use 'libname.a' as a failure fallback in this case? The load library gets the entire library name, after construction from dll_build_name. This is always a .so file name. When .so file name fails to load, we fallback to .a filename. Do i need to mention the filename as libfilename.so then ? - PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1472417159
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v11]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: update comment - Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/cbad4f9a..257f5def Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16604=10 - incr: https://webrevs.openjdk.org/?repo=jdk=16604=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v10]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: update comment for reveiew - Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/212f16be..cbad4f9a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16604=09 - incr: https://webrevs.openjdk.org/?repo=jdk=16604=08-09 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v9]
On Wed, 24 Jan 2024 07:30:27 GMT, Thomas Stuefe wrote: > For me the unresolved question is still: > > * do we want an unconditional load of *.a for a given *.so (have yet to see > any documentation for this a-file duality) Yes. The documentation link - https://www.ibm.com/docs/en/aix/7.3?topic=memory-shared-objects-run-time-linking The text **In dynamic mode, input files specified with the -l flag may end in .so, as well as in .a. That is, a reference to -lfoo is satisfied by the first libfoo.so or libfoo.a found in any of the directories being searched. Dynamic mode is in effect by default unless the -bstatic option is used.** https://www.ibm.com/docs/en/aix/7.3?topic=l-ld-command Archive files are composite objects, which usually contain import files and object files, including shared objects. If an archive file contains another archive file or a member whose type is not recognized, the ld command issues a warning and ignores the unrecognized member. If an object file contained in an archive file has the F_LOADONLY bit set in the XCOFF header, the ld command ignores the member. This bit is usually used to designate old versions of shared objects that remain in the archive file to allow existing applications to load and run. New applications link with the new version of the shared object, that is, another member of the archive. > * if we do, do we want that to be bidirectional? Someone specifies *.a, do we > want to attempt to load *.so? > Considering the different scenarios, loading .a after .so failure should suffice. I got a chance to look at the right file in OpenJ9-omr ,which has a native code which does an attempt to load archive files after trying to load .so files. This code was always there and it explains why the issue did not occur in Semeru, which is derived from this repository. > When in doubt, we should just mimic what OpenJ9 is doing on AIX. But I would > like a clear documentation as a comment in os_aix.cpp explaining the logic > and referencing the relevant OpenJ9 files. > Any example comment you can refer ? I mean i just mention the file name in OpenJ9 and explain the logic ? Let me know for any further clarifications - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1909927553
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v7]
On Thu, 21 Dec 2023 10:01:04 GMT, Thomas Stuefe wrote: >>> > > What happens if we accidentally attempt to load a "real" static >>> > > library, which is also named *.a? Would dlopen() then crash? What would >>> > > happen? >>> >>> > I don't think the problem is with *.a . They would load as the default >>> > behaviour of the dlopen. It is only when the dlopen fails for *.so , we >>> > give another chance to check for .a file with the same name. >>> >>> No, what I meant, and what must be clarified before going forward with this >>> solution, is the following: >>> >>> * is _every_ `*.a` object on AIX loadable with `dlopen`, and will the >>> result be the same as when loading a `*.so` object >>> * or, if we present arbitrary `*.a` files to dlopen, is there a chance for >>> dlopen to crash or misbehave. >>> >>> Reason is that I was under the impression that *.a libraries are static >>> libraries and cannot be loaded dynamically. This is what you now try to do. >>> If we cannot safely answer this question, I would opt for a more narrow >>> solution by hard-wiring known alternative names. So, do the second *.a >>> attempt only for your `ibm_16_am.a` which you know works. That could also >>> be done in a reasonably maintainable manner. >>> >> In AIX, both static and dynamic libraries have *.a extension. And AIX also >> supports *.so files.Bascially shared objects in AIX have both *.a and *.so >> extension. Hence we need to implement this logic. >> If we try loading a static archive specifically ,how the dlopen would behave >> , that is something probably @JoKern65 can answer ? >> >> >>> > > Does this really have to be handled in the OpenJDK? What does J9 on AIX >>> > > do? Could this be done in a simpler way outside OpenJDK, e.g. by >>> > > providing an *.so variant of the library in question? Where does this >>> > > library come from? >>> >>> > I am not sure how J9 handles this. I would have to consult . >>> >>> J9 is Open Source, can't you just look? :) >> >> I did try comparing the file structures, and i do not see a similar file >> structure over there. >> I am unable to find the jvmTiAgent code and also os_aix file. So i am not >> sure which functions over there are doing the same functionality. You have >> any suggestion on how i can check and correlate ? >>> >>> > However as per current observation, this issue does not show up on >>> > Semuru. This issue is only happening on Adoptium. The team that release >>> > these file has always released *.a files which work fine for Semuru. >>> >>> I don't know what Semuru is. What is the context, is that a different VM? >>> Also OpenJDK? J9 derived? >> >> >> Semuru is J9 derived. > >> > > > What happens if we accidentally attempt to load a "real" static >> > > > library, which is also named *.a? Would dlopen() then crash? What >> > > > would happen? >> > >> > >> > > I don't think the problem is with *.a . They would load as the default >> > > behaviour of the dlopen. It is only when the dlopen fails for *.so , we >> > > give another chance to check for .a file with the same name. >> > >> > >> > No, what I meant, and what must be clarified before going forward with >> > this solution, is the following: >> > >> > * is _every_ `*.a` object on AIX loadable with `dlopen`, and will the >> > result be the same as when loading a `*.so` object >> > * or, if we present arbitrary `*.a` files to dlopen, is there a chance for >> > dlopen to crash or misbehave. >> > >> > Reason is that I was under the impression that *.a libraries are static >> > libraries and cannot be loaded dynamically. This is what you now try to do. >> > If we cannot safely answer this question, I would opt for a more narrow >> > solution by hard-wiring known alternative names. So, do the second *.a >> > attempt only for your `ibm_16_am.a` which you know works. That could also >> > be done in a reasonably maintainable manner. >> >> In AIX, both static and dynamic libraries have *.a extension. And AIX also >> supports *.so files.Bascially shared objects in AIX have both *.a and *.so >> extension. Hence we need to implement this logic. If we try loading a static >> archive specifically ,how the dlopen would behave , that is something >> probably @JoKern65 can answer ? > > Rather, this is a question you have to ask your collegues at IBM that develop > the AIX libc. > > Since AIX libc is not open source, we cannot look for ourselves, nor can > Joachim (her works at SAP). > >> >> > > > Does this really have to be handled in the OpenJDK? What does J9 on >> > > > AIX do? Could this be done in a simpler way outside OpenJDK, e.g. by >> > > > providing an *.so variant of the library in question? Where does this >> > > > library come from? >> > >> > >> > > I am not sure how J9 handles this. I would have to consult . >> > >> > >> > J9 is Open Source, can't you just look? :) >> >> I did try comparing the file structures, and i do not see a
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v7]
On Tue, 16 Jan 2024 16:12:16 GMT, Martin Doerr wrote: > > I have tried to build jextract > > (https://github.com/openjdk/jextract/tree/jdk22) with LLVM > > (https://github.com/llvm/llvm-project/releases/download/llvmorg-16.0.4/clang+llvm-16.0.4-powerpc64-ibm-aix-7.2.tar.xz). > > I noticed that llvm mainly consists of .a files. So, I think we need to > > support that for FFI compatibility with other libraries and open source > > projects. > > Seems like this change is not sufficient for that. `clang` is compiled to > `libclang.a` on AIX, but `libclang.so` on linux. I'm getting "System error: > Exec format error" when trying to load `libclang.a` via > `System.loadLibrary(libName);`. So the question remains: Are .a files really > supposed to be dynamically loadable on AIX? If so, where is that documented? Yes we have rhe case where .a files are dynamically loadable as well on AIX. - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1905321150
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v7]
On Wed, 20 Dec 2023 13:29:05 GMT, Joachim Kern wrote: >> Suchismith Roy has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Spaces fix > > src/hotspot/os/aix/os_aix.cpp line 1168: > >> 1166: int extension_length = 3; >> 1167: char* file_path = NEW_C_HEAP_ARRAY(char, buffer_length + >> extension_length + 1, mtInternal); >> 1168: strncpy(file_path,filename, buffer_length + 1); > > Why not using > `char* file_path = os::strdup (filename);` > which would replace lines 1167+1168 > and use the corresponding > `os::free (file_path);` > at the end Ok. Any performance advantage to using that ? - PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1453094259
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v9]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision: - Update porting_aix.cpp - Update porting_aix.cpp - Update os_aix.cpp - Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/6a5ce4a2..212f16be Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16604=08 - incr: https://webrevs.openjdk.org/?repo=jdk=16604=07-08 Stats: 6 lines in 2 files changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v8]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: - Fix merge conflicts - Spaces fix - Restore lines - Remove trailing spaces. - Change return type - Change dll load function signature that does dlopen - Remove AIX macros - Add wrapper function to check extension before dlopen - merge pr/16920 - cosmetic changes - ... and 14 more: https://git.openjdk.org/jdk/compare/36f4b34f...6a5ce4a2 - Changes: https://git.openjdk.org/jdk/pull/16604/files Webrev: https://webrevs.openjdk.org/?repo=jdk=16604=07 Stats: 28 lines in 2 files changed: 27 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v7]
On Thu, 21 Dec 2023 10:01:04 GMT, Thomas Stuefe wrote: >>> > > What happens if we accidentally attempt to load a "real" static >>> > > library, which is also named *.a? Would dlopen() then crash? What would >>> > > happen? >>> >>> > I don't think the problem is with *.a . They would load as the default >>> > behaviour of the dlopen. It is only when the dlopen fails for *.so , we >>> > give another chance to check for .a file with the same name. >>> >>> No, what I meant, and what must be clarified before going forward with this >>> solution, is the following: >>> >>> * is _every_ `*.a` object on AIX loadable with `dlopen`, and will the >>> result be the same as when loading a `*.so` object >>> * or, if we present arbitrary `*.a` files to dlopen, is there a chance for >>> dlopen to crash or misbehave. >>> >>> Reason is that I was under the impression that *.a libraries are static >>> libraries and cannot be loaded dynamically. This is what you now try to do. >>> If we cannot safely answer this question, I would opt for a more narrow >>> solution by hard-wiring known alternative names. So, do the second *.a >>> attempt only for your `ibm_16_am.a` which you know works. That could also >>> be done in a reasonably maintainable manner. >>> >> In AIX, both static and dynamic libraries have *.a extension. And AIX also >> supports *.so files.Bascially shared objects in AIX have both *.a and *.so >> extension. Hence we need to implement this logic. >> If we try loading a static archive specifically ,how the dlopen would behave >> , that is something probably @JoKern65 can answer ? >> >> >>> > > Does this really have to be handled in the OpenJDK? What does J9 on AIX >>> > > do? Could this be done in a simpler way outside OpenJDK, e.g. by >>> > > providing an *.so variant of the library in question? Where does this >>> > > library come from? >>> >>> > I am not sure how J9 handles this. I would have to consult . >>> >>> J9 is Open Source, can't you just look? :) >> >> I did try comparing the file structures, and i do not see a similar file >> structure over there. >> I am unable to find the jvmTiAgent code and also os_aix file. So i am not >> sure which functions over there are doing the same functionality. You have >> any suggestion on how i can check and correlate ? >>> >>> > However as per current observation, this issue does not show up on >>> > Semuru. This issue is only happening on Adoptium. The team that release >>> > these file has always released *.a files which work fine for Semuru. >>> >>> I don't know what Semuru is. What is the context, is that a different VM? >>> Also OpenJDK? J9 derived? >> >> >> Semuru is J9 derived. > >> > > > What happens if we accidentally attempt to load a "real" static >> > > > library, which is also named *.a? Would dlopen() then crash? What >> > > > would happen? >> > >> > >> > > I don't think the problem is with *.a . They would load as the default >> > > behaviour of the dlopen. It is only when the dlopen fails for *.so , we >> > > give another chance to check for .a file with the same name. >> > >> > >> > No, what I meant, and what must be clarified before going forward with >> > this solution, is the following: >> > >> > * is _every_ `*.a` object on AIX loadable with `dlopen`, and will the >> > result be the same as when loading a `*.so` object >> > * or, if we present arbitrary `*.a` files to dlopen, is there a chance for >> > dlopen to crash or misbehave. >> > >> > Reason is that I was under the impression that *.a libraries are static >> > libraries and cannot be loaded dynamically. This is what you now try to do. >> > If we cannot safely answer this question, I would opt for a more narrow >> > solution by hard-wiring known alternative names. So, do the second *.a >> > attempt only for your `ibm_16_am.a` which you know works. That could also >> > be done in a reasonably maintainable manner. >> >> In AIX, both static and dynamic libraries have *.a extension. And AIX also >> supports *.so files.Bascially shared objects in AIX have both *.a and *.so >> extension. Hence we need to implement this logic. If we try loading a static >> archive specifically ,how the dlopen would behave , that is something >> probably @JoKern65 can answer ? > > Rather, this is a question you have to ask your collegues at IBM that develop > the AIX libc. > > Since AIX libc is not open source, we cannot look for ourselves, nor can > Joachim (her works at SAP). > >> >> > > > Does this really have to be handled in the OpenJDK? What does J9 on >> > > > AIX do? Could this be done in a simpler way outside OpenJDK, e.g. by >> > > > providing an *.so variant of the library in question? Where does this >> > > > library come from? >> > >> > >> > > I am not sure how J9 handles this. I would have to consult . >> > >> > >> > J9 is Open Source, can't you just look? :) >> >> I did try comparing the file structures, and i do not see a
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v7]
On Thu, 21 Dec 2023 10:01:04 GMT, Thomas Stuefe wrote: > > > > > What happens if we accidentally attempt to load a "real" static > > > > > library, which is also named *.a? Would dlopen() then crash? What > > > > > would happen? > > > > > > > > > > I don't think the problem is with *.a . They would load as the default > > > > behaviour of the dlopen. It is only when the dlopen fails for *.so , we > > > > give another chance to check for .a file with the same name. > > > > > > > > > No, what I meant, and what must be clarified before going forward with > > > this solution, is the following: > > > > > > * is _every_ `*.a` object on AIX loadable with `dlopen`, and will the > > > result be the same as when loading a `*.so` object > > > * or, if we present arbitrary `*.a` files to dlopen, is there a chance > > > for dlopen to crash or misbehave. > > > > > > Reason is that I was under the impression that *.a libraries are static > > > libraries and cannot be loaded dynamically. This is what you now try to > > > do. > > > If we cannot safely answer this question, I would opt for a more narrow > > > solution by hard-wiring known alternative names. So, do the second *.a > > > attempt only for your `ibm_16_am.a` which you know works. That could also > > > be done in a reasonably maintainable manner. > > > > > > In AIX, both static and dynamic libraries have *.a extension. And AIX also > > supports *.so files.Bascially shared objects in AIX have both *.a and *.so > > extension. Hence we need to implement this logic. If we try loading a > > static archive specifically ,how the dlopen would behave , that is > > something probably @JoKern65 can answer ? > > Rather, this is a question you have to ask your collegues at IBM that develop > the AIX libc. > > Since AIX libc is not open source, we cannot look for ourselves, nor can > Joachim (her works at SAP). > > > > > > Does this really have to be handled in the OpenJDK? What does J9 on > > > > > AIX do? Could this be done in a simpler way outside OpenJDK, e.g. by > > > > > providing an *.so variant of the library in question? Where does this > > > > > library come from? > > > > > > > > > > I am not sure how J9 handles this. I would have to consult . > > > > > > > > > J9 is Open Source, can't you just look? :) > > > > > > I did try comparing the file structures, and i do not see a similar file > > structure over there. I am unable to find the jvmTiAgent code and also > > os_aix file. So i am not sure which functions over there are doing the same > > functionality. You have any suggestion on how i can check and correlate ? > > Someone must implement LoadLibrary. Try looking for places where dlopen() is > called. > > > > > However as per current observation, this issue does not show up on > > > > Semuru. This issue is only happening on Adoptium. The team that release > > > > these file has always released *.a files which work fine for Semuru. > > > > > > > > > I don't know what Semuru is. What is the context, is that a different VM? > > > Also OpenJDK? J9 derived? > > > > > > Semuru is J9 derived. Ok , i was not able to find the right file yet. I will collaborate on this further once i am back from vacation, in January. - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1867498645
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v7]
On Wed, 20 Dec 2023 11:16:03 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared >> library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load >> fails.It fails to identify the shared library ibm_16_am.a shared archive >> file on AIX. >> Hence we are providing a function which will additionally search for .a file >> on AIX ,when the search for .so file fails. > > Suchismith Roy has updated the pull request incrementally with one additional > commit since the last revision: > > Spaces fix > > > What happens if we accidentally attempt to load a "real" static library, > > > which is also named *.a? Would dlopen() then crash? What would happen? > > > I don't think the problem is with *.a . They would load as the default > > behaviour of the dlopen. It is only when the dlopen fails for *.so , we > > give another chance to check for .a file with the same name. > > No, what I meant, and what must be clarified before going forward with this > solution, is the following: > > * is _every_ `*.a` object on AIX loadable with `dlopen`, and will the result > be the same as when loading a `*.so` object > * or, if we present arbitrary `*.a` files to dlopen, is there a chance for > dlopen to crash or misbehave. > > Reason is that I was under the impression that *.a libraries are static > libraries and cannot be loaded dynamically. This is what you now try to do. > If we cannot safely answer this question, I would opt for a more narrow > solution by hard-wiring known alternative names. So, do the second *.a > attempt only for your `ibm_16_am.a` which you know works. That could also be > done in a reasonably maintainable manner. > In AIX, both static and dynamic libraries have *.a extension. And AIX also supports *.so files.Bascially shared objects in AIX have both *.a and *.so extension. Hence we need to implement this logic. If we try loading a static archive specifically ,how the dlopen would behave , that is something probably @JoKern65 can answer ? > > > Does this really have to be handled in the OpenJDK? What does J9 on AIX > > > do? Could this be done in a simpler way outside OpenJDK, e.g. by > > > providing an *.so variant of the library in question? Where does this > > > library come from? > > > I am not sure how J9 handles this. I would have to consult . > > J9 is Open Source, can't you just look? :) I did try comparing the file structures, and i do not see a similar file structure over there. I am unable to find the jvmTiAgent code and also os_aix file. So i am not sure which functions over there are doing the same functionality. You have any suggestion on how i can check and correlate ? > > > However as per current observation, this issue does not show up on Semuru. > > This issue is only happening on Adoptium. The team that release these file > > has always released *.a files which work fine for Semuru. > > I don't know what Semuru is. What is the context, is that a different VM? > Also OpenJDK? J9 derived? Semuru is J9 derived. - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1865945011
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v7]
On Wed, 20 Dec 2023 14:30:18 GMT, Thomas Stuefe wrote: > Hi, > > some requests and questions: > > * Please modify the JBS title, PR title, and JBS issue text to reflect that > this adds an alternative shared object loading path for shared objects on > AIX. Something like "Allow loading shared objects with .a extension on AIX". > Please describe the new logic in the JBS issue text. > * Does this really have to be handled in the OpenJDK? What does J9 on AIX do? > Could this be done in a simpler way outside OpenJDK, e.g. by providing an > *.so variant of the library in question? Where does this library come from? > * What happens if we accidentally attempt to load a "real" static library, > which is also named *.a? Would dlopen() then crash? What would happen? > * What happens if the original path handed to os::dll_load is already a *.a > file? Should the logic then be reversed? > * We really need regression tests for this. For some of the question I need to consult the folk working on J9. I will answer a few of them if that gives some clarity. > * Please modify the JBS title, PR title, and JBS issue text to reflect that > this adds an alternative shared object loading path for shared objects on > AIX. Something like "Allow loading shared objects with .an extension on AIX". > Please describe the new logic in the JBS issue text. Sure working on it. > * Does this really have to be handled in the OpenJDK? What does J9 on AIX do? > Could this be done in a simpler way outside OpenJDK, e.g. by providing an > *.so variant of the library in question? Where does this library come from? I am not sure how J9 handles this. I would have to consult . However as per current observation, this issue does not show up on Semuru. This issue is only happening on Adoptium. The team that release these file has always released *.a files which work fine for Semuru. > * What happens if we accidentally attempt to load a "real" static library, > which is also named *.a? Would dlopen() then crash? What would happen? I don't think the problem is with *.a . They would load as the default behaviour of the dlopen. It is only when the dlopen fails for *.so , we give another chance to check for .a file with the same name. > * What happens if the original path handed to os::dll_load is already a *.a > file? Should the logic then be reversed? I don't think so. We are not modifying the behaviour to handle *.a files here. We are just adding extra checks for *.so files if they fail to load. In the logic , when a load fails, I just check if it is a .so file and perform the loading again. - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1865837275
Re: RFR: JDK-8320005 : Native library suffix impact on hotspot code in AIX [v7]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision: Spaces fix - Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/9df8c2c8..ffcbf786 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16604=06 - incr: https://webrevs.openjdk.org/?repo=jdk=16604=05-06 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Native library suffix impact on hotspot code in AIX [v2]
On Tue, 19 Dec 2023 16:47:33 GMT, Goetz Lindenmaier wrote: > try it! I got the instructions to replicate in my local repo later, so wasn't sure to proceed. Thanks for the suggestion. I think this makes it easier to keep in sync with the other change. - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1864127477
Re: RFR: JDK-8320005 : Native library suffix impact on hotspot code in AIX [v2]
On Tue, 28 Nov 2023 11:27:33 GMT, Suchismith Roy wrote:
> > > i would have to repeat the line 1132 and 1139 in os_aix.cpp again , if
> > > the condition fails for .so files, because i have to reload it again and
> > > check if the .a exists. In the shared code i had repeat less number of
> > > lines i believe. Do you suggest moving lines 1132 to 1139 to another
> > > function then ?
> >
> >
> > @tstuefe Any suggestion on this ?
>
> ```
> --- a/src/hotspot/os/aix/os_aix.cpp
> +++ b/src/hotspot/os/aix/os_aix.cpp
> @@ -1108,7 +1108,7 @@ bool os::dll_address_to_library_name(address addr,
> char* buf,
>return true;
> }
>
> -void *os::dll_load(const char *filename, char *ebuf, int ebuflen) {
> +static void* dll_load_inner(const char *filename, char *ebuf, int ebuflen) {
>
>log_info(os)("attempting shared library load of %s", filename);
>
> @@ -1158,6 +1158,35 @@ void *os::dll_load(const char *filename, char *ebuf,
> int ebuflen) {
>return nullptr;
> }
>
> +void* os::dll_load(const char *filename, char *ebuf, int ebuflen) {
> +
> + void* result = nullptr;
> +
> + // First try using *.so suffix; failing that, retry with *.a suffix.
> + const size_t len = strlen(filename);
> + constexpr size_t safety = 3 + 1;
> + constexpr size_t bufsize = len + safety;
> + char* buf = NEW_C_HEAP_ARRAY(char, bufsize, mtInternal);
> + strcpy(buf, filename);
> + char* const dot = strrchr(buf, '.');
> +
> + assert(dot != nullptr, "Attempting to load a shared object without
> extension? %s", filename);
> + assert(strcmp(dot, ".a") == 0 || strcmp(dot, ".so") == 0,
> + "Attempting to load a shared object that is neither *.so nor *.a",
> filename);
> +
> + sprintf(dot, ".so");
> + result = dll_load_inner(buf, ebuf, ebuflen);
> +
> + if (result == nullptr) {
> +sprintf(dot, ".a");
> +result = dll_load_inner(buf, ebuf, ebuflen);
> + }
> +
> + FREE_C_HEAP_ARRAY(char, buf);
> +
> + return result;
> +}
> +
> ```
Hi Thomas
May I know what is the reason to use constexpr over regular datatypes ?
Also, I have used strcpy to avoid buffer overflow.(Though we have calculated
the exact length). Would that be fine ?
-
PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1864063261
Re: RFR: JDK-8320005 : Native library suffix impact on hotspot code in AIX [v6]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision: - Restore lines - Remove trailing spaces. - Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/cd7e0e64..9df8c2c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16604=05 - incr: https://webrevs.openjdk.org/?repo=jdk=16604=04-05 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Native library suffix impact on hotspot code in AIX [v5]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request incrementally with four additional commits since the last revision: - Change return type - Change dll load function signature that does dlopen - Remove AIX macros - Add wrapper function to check extension before dlopen - Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/eb09224d..cd7e0e64 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16604=04 - incr: https://webrevs.openjdk.org/?repo=jdk=16604=03-04 Stats: 34 lines in 2 files changed: 22 ins; 11 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Native library suffix impact on hotspot code in AIX [v4]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains eight new commits since the last revision: - merge pr/16920 - change macro position - Adapt hotspot coding style - Improve comments and coding style. - Remove macro for file extension. - Move mapping function to aix specific file. - Introduce new macro for AIX archives. - Add support for .a extension in jvm agent. 1. Add support to load archive files and shared objects in jvm agent for AIX. - Changes: - all: https://git.openjdk.org/jdk/pull/16604/files - new: https://git.openjdk.org/jdk/pull/16604/files/151f6c20..eb09224d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16604=03 - incr: https://webrevs.openjdk.org/?repo=jdk=16604=02-03 Stats: 3 lines in 2 files changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Native library suffix impact on hotspot code in AIX [v2]
On Tue, 19 Dec 2023 16:47:33 GMT, Goetz Lindenmaier wrote: > try it! error: failed to push some refs to 'github.com:suchismith1993/jdk.git' I tried the fork instructions . However I think I need to do a force push. Will that be fine since the PR is not in draft state ? - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1863210891
Re: RFR: JDK-8320005 : Native library suffix impact on hotspot code in AIX [v3]
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a function which will additionally search for .a file > on AIX ,when the search for .so file fails. Suchismith Roy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge branch 'pr/16920' into jvmagent - change macro position - Adapt hotspot coding style - Improve comments and coding style. - Remove macro for file extension. - Move mapping function to aix specific file. - Introduce new macro for AIX archives. - Add support for .a extension in jvm agent. 1. Add support to load archive files and shared objects in jvm agent for AIX. - Changes: https://git.openjdk.org/jdk/pull/16604/files Webrev: https://webrevs.openjdk.org/?repo=jdk=16604=02 Stats: 13 lines in 3 files changed: 13 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16604.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604 PR: https://git.openjdk.org/jdk/pull/16604
Re: RFR: JDK-8320005 : Native library suffix impact on hotspot code in AIX [v2]
On Tue, 19 Dec 2023 13:55:09 GMT, Suchismith Roy wrote: >>> > > >>> > >>> > >>> > @tstuefe 3rd parameter to pass the either of 2 things: >>> > ``` >>> > 1. The JvmTiAgent object "agent", so that after shifting the >>> > save_library_signature to os_aix,we can still access the agent object.-> >>> > For this i tried importing jvm/prims header file, but i get segmentation >>> > faults during build . Not sure if i am doing it the right way. >>> > >>> > 2. Pass a character buffer(and not const char*) where we copy the >>> > modified filename back to it and then use it in jvmAgent. code. >>> > ``` >>> >>> Does not sound really appealing tbh. We pile one hack atop of another. >>> >>> Please synchronize with @JoKern65 at SAP. He will rewrite the JVMTI handler >>> code, which will make this point moot. See >>> https://bugs.openjdk.org/browse/JDK-8320890. >> >> Hi @tstuefe Should i then wait for this code to be integrated and then >> rewrite the .a handling ? >> I mean this PR shall remain open then right ? >> @JoKern65 Are you even handling the .a handling case ? i would like this PR >> to stay open. Maybe i can wait for the design change that you are working on. > >> Hi @suchismith1993 , you can place this change on top of #16920 by comparing >> it with branch origin/pr/16920 instead of master. This way you might be able >> to proceed with your change. But as Thomas says you can only push if you >> have appropriate reviews. > > Hi @GoeLin I am not sure how to do that . Could you tell me in brief ? > Do I run the checkout command on the other PR and then place my change of top > of it ? > > > Hi @suchismith1993 , you can place this change on top of #16920 by > > > comparing it with branch origin/pr/16920 instead of master. This way you > > > might be able to proceed with your change. But as Thomas says you can > > > only push if you have appropriate reviews. > > > > > > Hi @GoeLin I am not sure how to do that . Could you tell me in brief ? Do I > > run the checkout command on the other PR and then place my change of top of > > it ? > > Yes, you can do that. You can also change the branch in this pr. Click edit > on the top right. Choose an alternative for "openjdk:master" I see. So If I do that, will it reflect on my command line in local machine ? I mean I need run a rebase command with origin as pr/16920 ? - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1863086746
Re: RFR: JDK-8320005 : Native library suffix impact on hotspot code in AIX [v2]
On Tue, 28 Nov 2023 12:59:01 GMT, Suchismith Roy wrote: >>> > >>> >>> @tstuefe 3rd parameter to pass the either of 2 things: >>> >>> 1. The JvmTiAgent object "agent", so that after shifting the >>> save_library_signature to os_aix,we can still access the agent object.-> >>> For this i tried importing jvm/prims header file, but i get segmentation >>> faults during build . Not sure if i am doing it the right way. >>> >>> 2. Pass a character buffer(and not const char*) where we copy the >>> modified filename back to it and then use it in jvmAgent. code. >> >> Does not sound really appealing tbh. We pile one hack atop of another. >> >> Please synchronize with @JoKern65 at SAP. He will rewrite the JVMTI handler >> code, which will make this point moot. See >> https://bugs.openjdk.org/browse/JDK-8320890. > >> > > >> > >> > >> > @tstuefe 3rd parameter to pass the either of 2 things: >> > ``` >> > 1. The JvmTiAgent object "agent", so that after shifting the >> > save_library_signature to os_aix,we can still access the agent object.-> >> > For this i tried importing jvm/prims header file, but i get segmentation >> > faults during build . Not sure if i am doing it the right way. >> > >> > 2. Pass a character buffer(and not const char*) where we copy the modified >> > filename back to it and then use it in jvmAgent. code. >> > ``` >> >> Does not sound really appealing tbh. We pile one hack atop of another. >> >> Please synchronize with @JoKern65 at SAP. He will rewrite the JVMTI handler >> code, which will make this point moot. See >> https://bugs.openjdk.org/browse/JDK-8320890. > > Hi @tstuefe Should i then wait for this code to be integrated and then > rewrite the .a handling ? > I mean this PR shall remain open then right ? > @JoKern65 Are you even handling the .a handling case ? i would like this PR > to stay open. Maybe i can wait for the design change that you are working on. > Hi @suchismith1993 , you can place this change on top of #16920 by comparing > it with branch origin/pr/16920 instead of master. This way you might be able > to proceed with your change. But as Thomas says you can only push if you have > appropriate reviews. Hi @GoeLin I am not sure how to do that . Could you tell me in brief ? Do I run the checkout command on the other PR and then place my change of top of it ? - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1862802768
Re: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle equality [v4]
On Tue, 19 Dec 2023 12:52:23 GMT, Thomas Stuefe wrote: >> Hi @JoKern65 Is this good to integrate now ? > > @suchismith1993 > >> Once this code goes in I can push in my changes. We are targeting the fix >> for January. > > If you talk about https://github.com/openjdk/jdk/pull/16604, no, you cannot > push that even if Joachim finishes his work. > > Your patch has not even a single review, is quite controversial, and none of > the issues the reviewers have mentioned are addressed. This needs a lot more > discussion time. > > @tstuefe Sorry to tag you. Can you review the code. Once this code goes in > > I can push in my changes. > > We are targeting the fix for January. > > > Hi @JoKern65 Is this good to integrate now ? > > @suchismith1993 Please don't put pressure on patch authors and developers. > There is zero reason why this patch should be rushed. > > > Hi @suchismith1993, I'm waiting for a second review. Complex hotspot > > changes should be reviewed twice. > > Not only that, hotspot changes _need_ to be reviewed by at least two > reviewers. That is not optional. See OpenJDK bylaws. Sorry about that. The fix was critical for the adoptium builds and hence was looking to fix this soon. - PR Comment: https://git.openjdk.org/jdk/pull/16920#issuecomment-1862776678
Re: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle equality [v4]
On Tue, 19 Dec 2023 12:37:33 GMT, Suchismith Roy wrote: >> The libpath parsing code is from me, so no license problems. > > Hi @JoKern65 Is this good to integrate now ? > @suchismith1993 > > > Once this code goes in I can push in my changes. We are targeting the fix > > for January. > > If you talk about #16604, no, you cannot push that even if Joachim finishes > his work. > > Your patch has not even a single review, is quite controversial, and none of > the issues the reviewers have mentioned are addressed. This needs a lot more > discussion time. I have the patch ready based on the changes in this patch, as I take the diff and apply. But I cannot push since it will end up adding the entire file. - PR Comment: https://git.openjdk.org/jdk/pull/16920#issuecomment-1862768974
Re: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle equality [v4]
On Fri, 15 Dec 2023 11:51:43 GMT, Joachim Kern wrote: >> Joachim Kern has updated the pull request incrementally with one additional >> commit since the last revision: >> >> followed the proposals > > The libpath parsing code is from me, so no license problems. Hi @JoKern65 Is this good to integrate now ? - PR Comment: https://git.openjdk.org/jdk/pull/16920#issuecomment-1862684040
Re: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle equality [v3]
On Tue, 5 Dec 2023 13:48:11 GMT, Thomas Stuefe wrote: >> Joachim Kern has updated the pull request incrementally with one additional >> commit since the last revision: >> >> encapsulate everything in os::Aix::dlopen > > Excellent, this is how I have pictured a good solution. Very nice. > > A number of remarks, but nothing fundamental. @tstuefe Sorry to tag you. Can you review the code. Once this code goes in I can push in my changes. We are targeting the fix for January. - PR Comment: https://git.openjdk.org/jdk/pull/16920#issuecomment-1856145815
