JDK-8276572: Fake libsyslookup.so library causes tooling issues

[gnu-andrew]

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.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8276572: Fake libsyslookup.so library causes tooling issues

Reviewers

• Aleksey Shipilev (@shipilev - Reviewer)
• Maurizio Cimadamore (@mcimadamore - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/6245/head:pull/6245
$ git checkout pull/6245

Update a local copy of the PR:
$ git checkout pull/6245
$ git pull https://git.openjdk.java.net/jdk pull/6245/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 6245

View PR using the GUI difftool:
$ git pr show -t 6245

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/6245.diff

[bridgekeeper]

👋 Welcome back andrew! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@gnu-andrew The following label will be automatically applied to this pull request:

• core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (9d94e51f)

[shipilev]

This makes sense to me, but @mcimadamore should ack this.

[mcimadamore]

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?

[openjdk]

@gnu-andrew This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8276572: Fake libsyslookup.so library causes tooling issues

Reviewed-by: shade, mcimadamore

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 30 new commits pushed to the master branch:

• 96c396b: 8276151: AArch64: Incorrect result for double to int vector conversion
• 7281861: 8272065: jcmd cannot rely on the old core reflection implementation which will be changed after JEP 416
• 8e17ce0: 8275185: Remove dead code and clean up jvmstat LocalVmManager
• 396132f: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds
• 9ad4d3d: 8276025: Hotspot's libsvml.so may conflict with user dependency
• e21b5c7: 8276650: GenGraphs does not produce deterministic output
• 7b1916e: 8233557: [TESTBUG] DoubleClickTitleBarTest.java fails on macOs
• 8ec80c4: 8276653: Missing row headers in j.l.Character docs
• 7e87f94: 8276652: Missing row headers in MethodHandles.Lookup docs
• dcf36f8: 8275670: ciReplay: java.lang.NoClassDefFoundError when trying to load java/lang/invoke/LambdaForm$MH
• ... and 20 more: https://git.openjdk.java.net/jdk/compare/603bba282a089928fd23f8da23a7c1b2d52944ef...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[judovana]

Most likely bad idea, but isnt there an threat, that the method will be dropped by optimising compiler?

[mcimadamore]

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.

[gnu-andrew]

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.

[gnu-andrew]

Ok, if it works, it's still going to be messy, as we have to disable this warning:

/home/andrew/projects/openjdk/upstream/jdk/src/jdk.incubator.foreign/share/native/libsyslookup/syslookup.c:31:14: error: 'syslookup' defined but not used [-Werror=unused-function]
 static char* syslookup() {
              ^~~~~~~~~

[shipilev]

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.

[judovana]

Shouldn't the single volatile variable around prevent that?

[mcimadamore]

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.

[gnu-andrew]

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.

[gnu-andrew]

/integrate

[openjdk]

Going to push as commit a472433.
Since your change was applied there have been 40 commits pushed to the master branch:

• b01f107: 8276252: java/nio/channels/Channels/TransferTo.java failed with OOM java heap space error
• 92d2176: 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12
• a74a839: 8276571: C2: pass compilation options as structure
• c393ee8: 8276632: Use blessed modifier order in security-libs code
• 7023b3f: 8276628: Use blessed modifier order in serviceability code
• b933136: 8276641: Use blessed modifier order in jshell
• 0616d86: 8276635: Use blessed modifier order in compiler code
• d95299a: 8276634: Remove usePlainDatagramSocketImpl option from the test DatagramChannel/SendReceiveMaxSize.java
• 3c0faa7: 8276173: Clean up and remove unneeded casts in HeapDumper
• 323d201: 8275506: Rename allocated_on_stack to allocated_on_stack_or_embedded
• ... and 30 more: https://git.openjdk.java.net/jdk/compare/603bba282a089928fd23f8da23a7c1b2d52944ef...master

Your commit was automatically rebased without conflicts.

[openjdk]

@gnu-andrew Pushed as commit a472433.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

[gnu-andrew]

/backport 17u

[openjdk]

@gnu-andrew Unknown command backport - for a list of valid commands use /help.

[gnu-andrew]

/help

[openjdk]

@gnu-andrew Available commands:

• covered - used when employer has signed the OCA
• help - shows this text
• signed - used after signing the OCA
• test - used to run tests

[gnu-andrew]

Ok, I see, it has to be issued on the commit... didn't realise you could comment on such things.