RFR: JDK-8320005 : Native library suffix impact on hotspot code in AIX [v2]

[Thomas Stuefe]

On Thu, 23 Nov 2023 17:05:29 GMT, suchismith1993 <duke at openjdk.org> wrote:

> > I'm not a big fan of this approach. We accumulate more and more "#ifdef AIX" in shared code because of many recent AIX additions. No other platform has such a large ifdef footprint in shared code.
> > I argue that all of this should be handled inside os_aix.cpp and not leak out into the external space:
> > If .a is a valid shared object format on AIX, this should be handled in `os::dll_load()`, and be done for all shared objects. If not, why do we try to load a static archive via dlload in this case but not in other cases?
> > _If_ this is needed in shared code, the string replacement function should be a generic utility function for all platforms, and it should be tested with a small gtest. A gtest would have likely uncovered the buffer overflow too.
> 
> So i tried to check how to move the code to os_aix file. A few problems is see :
> 
> 1. When i have to implemented the logic at dll_load function, i would have to repeat a lot of code after dlopen, i.e i have to call dlopen again for .so files and hence i have to copy the logic again for it.
> 2. Currently using function before dll_load,in the shared code makes this a bit easier.
>    I have an alternate suggestion .
>    Shall we declare the utlity function as part of os ? and implement it platform wise.

Not without any need. If this is an AIX specific issue, it should be handed in os::dll_load on AIX.

>    In that way we just keep the actual implentation and aix and in windows and linux we keep it empty.
>    So that way we can just call the utility function in shared code and it wouldnt affect other platform and will run the usecase for AIX.
>    If that is not acceptable, then is there a better way to avoid repeating the dlopen again in os_aix file ?

I don't understand the problem. What is preventing you from using a file local scope utility function inside os::dll_load?

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

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