On Thu, 23 Nov 2023 17:05:29 GMT, suchismith1993 <d...@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

Reply via email to