RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols

[Erik Joelsson]

On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 <duke at openjdk.org> wrote:

> 1. Adding required compiler flags.
> 2. Adding required symbols.
> 
> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799)

> Problem: There is syslookup file which expects the required symbols to be exported using the compiler flags, that are mentioned in the Lib.gmk file. The math library in AIX specifically, is a static archive. Doing a -lm wont suffice, because when the symbols are looked up using dlsym or accessing native code through Java, it will lead to failures. Hence we had to come up with a list of symbols to allow math library symbols to be accesible. Also, there are parts of libc library that are static too, and hence those symbols also are present in this list. Without this change, the StdLibTest and multiple other tests which make native function calls using FFI, fail with NoSuchElementException.

> For some context: `java.lang.foreign.Linker.nativeLinker().defaultLookup()` returns a `SymbolLookup` that can be used to find symbols from the standard library.
> 
> We use a shim library that re-exports symbols from the standard library in order to make them accessible through `dlsym`, since on e.g. Linux the standard library .so files might actually be linker scripts which we don't want to mess with. On Windows we use ucrtbase.dll + an auxiliary library that contains the expansions of several 'inline' functions such as `printf`. I'm not surprised to see that another platform like AIX requires more to make this work as well.
> 
> That said, I think we should limit the exported symbols to only those found in the standard C library header files: https://en.cppreference.com/w/c/header

Could the list of symbols be dynamically extracted at build time in some way or is the set stable enough to basically never change?

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

PR Comment: https://git.openjdk.org/jdk/pull/16414#issuecomment-1804283653