RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v22]

Thomas Stuefe stuefe at openjdk.org
Fri Feb 16 12:53:01 UTC 2024


On Fri, 16 Feb 2024 12:25:39 GMT, Suchismith Roy <sroy at openjdk.org> 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.

Ah, okay. No, IBMs dlopen page for AIX refers to this page for the list of possible error codes; I assume dlopen just uses these functions under the hood.

> 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 ?

No. I mean distinguish whether dlopen fails because it could not find the file (a valid reason to retry with *.a) or failed for another reason (which would not be a valid reason to retry with *.a).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1948333340


More information about the serviceability-dev mailing list