RFR: JDK-8276572: Fake libsyslookup.so library causes tooling issues
The lack of anything to compile in `syslookup.c` is leading to a number of issues in our tooling, on some architectures more than others (s390x seems to be the most problematic). They expect to be able to retrieve debuginfo and compiler flags from generated .so files and fail with libsyslookup.so This simple patch adds a dummy function to `syslookup.c` so it appears more like a regular file to be compiled. I can't see this causing a problem with the symbol lookup, but we could filter it out on the Java side if need be. ------------- Commit messages: - JDK-8276572: Fake libsyslookup.so library causes tooling issues Changes: https://git.openjdk.java.net/jdk/pull/6245/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6245&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276572 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6245.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6245/head:pull/6245 PR: https://git.openjdk.java.net/jdk/pull/6245
On Thu, 4 Nov 2021 04:19:02 GMT, Andrew John Hughes <andrew@openjdk.org> wrote:
The lack of anything to compile in `syslookup.c` is leading to a number of issues in our tooling, on some architectures more than others (s390x seems to be the most problematic). They expect to be able to retrieve debuginfo and compiler flags from generated .so files and fail with libsyslookup.so
This simple patch adds a dummy function to `syslookup.c` so it appears more like a regular file to be compiled. I can't see this causing a problem with the symbol lookup, but we could filter it out on the Java side if need be.
This makes sense to me, but @mcimadamore should ack this. ------------- PR: https://git.openjdk.java.net/jdk/pull/6245
On Thu, 4 Nov 2021 04:19:02 GMT, Andrew John Hughes <andrew@openjdk.org> wrote:
The lack of anything to compile in `syslookup.c` is leading to a number of issues in our tooling, on some architectures more than others (s390x seems to be the most problematic). They expect to be able to retrieve debuginfo and compiler flags from generated .so files and fail with libsyslookup.so
This simple patch adds a dummy function to `syslookup.c` so it appears more like a regular file to be compiled. I can't see this causing a problem with the symbol lookup, but we could filter it out on the Java side if need be.
Looks ok. As long as we don't introduce more dependencies. One question: would introducing a static function (so, not visible in the resulting DLL) be good enough? ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6245
On Thu, 4 Nov 2021 12:40:15 GMT, Maurizio Cimadamore <mcimadamore@openjdk.org> wrote:
Looks ok. As long as we don't introduce more dependencies.
One question: would introducing a static function (so, not visible in the resulting DLL) be good enough?
I did wonder about this too. I'll have to check it still resolves the issues we see before updating the PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/6245
On Thu, 4 Nov 2021 04:19:02 GMT, Andrew John Hughes <andrew@openjdk.org> wrote:
The lack of anything to compile in `syslookup.c` is leading to a number of issues in our tooling, on some architectures more than others (s390x seems to be the most problematic). They expect to be able to retrieve debuginfo and compiler flags from generated .so files and fail with libsyslookup.so
This simple patch adds a dummy function to `syslookup.c` so it appears more like a regular file to be compiled. I can't see this causing a problem with the symbol lookup, but we could filter it out on the Java side if need be.
Most likely bad idea, but isnt there an threat, that the method will be dropped by optimising compiler? ------------- PR: https://git.openjdk.java.net/jdk/pull/6245
On Thu, 4 Nov 2021 20:12:52 GMT, Jiří Vaněk <jvanek@openjdk.org> wrote:
Most likely bad idea, but isnt there an threat, that the method will be dropped by optimising compiler?
It is a possibility that the function will be dropped, but maybe worth a try. ------------- PR: https://git.openjdk.java.net/jdk/pull/6245
On Thu, 4 Nov 2021 04:19:02 GMT, Andrew John Hughes <andrew@openjdk.org> wrote:
The lack of anything to compile in `syslookup.c` is leading to a number of issues in our tooling, on some architectures more than others (s390x seems to be the most problematic). They expect to be able to retrieve debuginfo and compiler flags from generated .so files and fail with libsyslookup.so
This simple patch adds a dummy function to `syslookup.c` so it appears more like a regular file to be compiled. I can't see this causing a problem with the symbol lookup, but we could filter it out on the Java side if need be.
Ok, if it works, it's still going to be messy, as we have to disable this warning: ~~~~ ------------- PR: https://git.openjdk.java.net/jdk/pull/6245
On Thu, 4 Nov 2021 04:19:02 GMT, Andrew John Hughes <andrew@openjdk.org> wrote:
The lack of anything to compile in `syslookup.c` is leading to a number of issues in our tooling, on some architectures more than others (s390x seems to be the most problematic). They expect to be able to retrieve debuginfo and compiler flags from generated .so files and fail with libsyslookup.so
This simple patch adds a dummy function to `syslookup.c` so it appears more like a regular file to be compiled. I can't see this causing a problem with the symbol lookup, but we could filter it out on the Java side if need be.
Marked as reviewed by shade (Reviewer). What do we have to lose if we have the non-static method in this library? I think it is less risky and intrusive than disabling warnings, making sure linkers are not removing the unused definiton, etc. IIRC, some toolchains (S390?) have linkers configured to strip unused symbols. Let's go with the PR in its current form. ------------- PR: https://git.openjdk.java.net/jdk/pull/6245
On Thu, 4 Nov 2021 04:19:02 GMT, Andrew John Hughes <andrew@openjdk.org> wrote:
The lack of anything to compile in `syslookup.c` is leading to a number of issues in our tooling, on some architectures more than others (s390x seems to be the most problematic). They expect to be able to retrieve debuginfo and compiler flags from generated .so files and fail with libsyslookup.so
This simple patch adds a dummy function to `syslookup.c` so it appears more like a regular file to be compiled. I can't see this causing a problem with the symbol lookup, but we could filter it out on the Java side if need be.
Shouldn't the single volatile variable around prevent that? ------------- PR: https://git.openjdk.java.net/jdk/pull/6245
On Thu, 4 Nov 2021 04:19:02 GMT, Andrew John Hughes <andrew@openjdk.org> wrote:
The lack of anything to compile in `syslookup.c` is leading to a number of issues in our tooling, on some architectures more than others (s390x seems to be the most problematic). They expect to be able to retrieve debuginfo and compiler flags from generated .so files and fail with libsyslookup.so
This simple patch adds a dummy function to `syslookup.c` so it appears more like a regular file to be compiled. I can't see this causing a problem with the symbol lookup, but we could filter it out on the Java side if need be.
For the records, I'm fine with proposed patch - I asked questions about possible alternatives. It seems like the alternatives work 50%, so let's go with proposed approach. ------------- PR: https://git.openjdk.java.net/jdk/pull/6245
On Thu, 4 Nov 2021 04:19:02 GMT, Andrew John Hughes <andrew@openjdk.org> wrote:
The lack of anything to compile in `syslookup.c` is leading to a number of issues in our tooling, on some architectures more than others (s390x seems to be the most problematic). They expect to be able to retrieve debuginfo and compiler flags from generated .so files and fail with libsyslookup.so
This simple patch adds a dummy function to `syslookup.c` so it appears more like a regular file to be compiled. I can't see this causing a problem with the symbol lookup, but we could filter it out on the Java side if need be.
Thanks. I agree the original feels safer and I'd rather avoid the ugly mess I needed with pragmas to get it to compile with an unused static function. ------------- PR: https://git.openjdk.java.net/jdk/pull/6245
On Thu, 4 Nov 2021 04:19:02 GMT, Andrew John Hughes <andrew@openjdk.org> wrote:
The lack of anything to compile in `syslookup.c` is leading to a number of issues in our tooling, on some architectures more than others (s390x seems to be the most problematic). They expect to be able to retrieve debuginfo and compiler flags from generated .so files and fail with libsyslookup.so
This simple patch adds a dummy function to `syslookup.c` so it appears more like a regular file to be compiled. I can't see this causing a problem with the symbol lookup, but we could filter it out on the Java side if need be.
This pull request has now been integrated. Changeset: a4724332 Author: Andrew John Hughes <andrew@openjdk.org> URL: https://git.openjdk.java.net/jdk/commit/a4724332098cd8bff44ee27e9190fd28fa5c... Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8276572: Fake libsyslookup.so library causes tooling issues Reviewed-by: shade, mcimadamore ------------- PR: https://git.openjdk.java.net/jdk/pull/6245
On Thu, 4 Nov 2021 04:19:02 GMT, Andrew John Hughes <andrew@openjdk.org> wrote:
The lack of anything to compile in `syslookup.c` is leading to a number of issues in our tooling, on some architectures more than others (s390x seems to be the most problematic). They expect to be able to retrieve debuginfo and compiler flags from generated .so files and fail with libsyslookup.so
This simple patch adds a dummy function to `syslookup.c` so it appears more like a regular file to be compiled. I can't see this causing a problem with the symbol lookup, but we could filter it out on the Java side if need be.
Ok, I see, it has to be issued on the commit... didn't realise you could comment on such things. ------------- PR: https://git.openjdk.java.net/jdk/pull/6245
participants (4)
-
Aleksey Shipilev
-
Andrew John Hughes
-
Jiří Vaněk
-
Maurizio Cimadamore