Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8303002: Reject packed structs from linker #13164

Closed
wants to merge 52 commits into from

Conversation

JornVernee
Copy link
Member

@JornVernee JornVernee commented Mar 23, 2023

This patch adds checks in AbstractLinker to reject packed structs and structs with excess padding (e.g. unnamed bitfields), since both of those are currently not supported, and the ABI/spec seems too vague to base support on.

/solves 8300784
/solves 8304803


Progress

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change requires CSR request JDK-8306631 to be approved

Issues

  • JDK-8303002: Reject packed structs from linker
  • JDK-8300784: Specify exactly how padding should be presented to the linker
  • JDK-8304803: NPE thrown during downcall classification under Linux/x64
  • JDK-8303524: Check FunctionDescriptor byte order when linking
  • JDK-8306631: Reject packed structs from linker (CSR)

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/13164/head:pull/13164
$ git checkout pull/13164

Update a local copy of the PR:
$ git checkout pull/13164
$ git pull https://git.openjdk.org/jdk.git pull/13164/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 13164

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/13164.diff

Webrev

Link to Webrev Comment

@bridgekeeper
Copy link

bridgekeeper bot commented Mar 23, 2023

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

@openjdk
Copy link

openjdk bot commented Mar 23, 2023

@JornVernee
Adding additional issue to solves list: 8300784: Specify exactly how padding should be presented to the linker.

@openjdk
Copy link

openjdk bot commented Mar 23, 2023

@JornVernee
Adding additional issue to solves list: 8304803: NPE thrown during downcall classification under Linux/x64.

@openjdk
Copy link

openjdk bot commented Mar 23, 2023

@JornVernee 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.

@openjdk openjdk bot added the core-libs core-libs-dev@openjdk.org label Mar 23, 2023
@JornVernee JornVernee changed the base branch from pr/13079 to pr/13161 March 27, 2023 13:26
@JornVernee JornVernee marked this pull request as ready for review March 27, 2023 13:53
@openjdk openjdk bot added the rfr Pull request is ready for review label Mar 27, 2023
@mlbridge
Copy link

mlbridge bot commented Mar 27, 2023

Webrevs

@@ -195,6 +196,18 @@
* <td style="text-align:center;">{@link MemorySegment}</td>
* </tbody>
* </table></blockquote>
* <p>
* Due to limited ABI specification coverage, all the native linker implementations limit the function
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All the native linker implementations support function function descriptors that contain only so-called...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, just drop the 'Due to limited ABI specification coverage'? I guess it's not really needed.

* <p>
* Due to limited ABI specification coverage, all the native linker implementations limit the function
* descriptors that they support to those that contain only so-called <em>canonical</em> layouts. These layouts
* have the following restrictions:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's better to phrase this more or less as:

A canonical layout has the following characteristics:
* Its alignment constraint is equal to its natural alignment
* If the layout is a value layout (linkplain), its byte order matches that of the platform in which the JVM is executing (link to nativeOrder())
*  If the layout is a group layout (linkplain), it must not contain more padding layout (linkplain) elements than those strictly necessary to satisfy the alignment constraints of the non-padding elements of the group layout.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, isn't it the case that, for structs, we want the size of the layout to be a multiple of its alignment constraint?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The third item in the list is for group size needing to be a multiple of the alignment constraint, the forth item refers to that, so I'll keep the ordered list.

WRT byte order: I think it's fine to just say "native byte order". Keep it simple. Or do you think there might be confusion about the meaning of "native"? (It looks like not even ByteOrder::nativeOrder explains that term: https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/nio/ByteOrder.html#nativeOrder())

"padding layout elements" is not quite right I think, since they also have to be the right size. I think saying just "padding" is more accurate (and simpler).

I'll switch to using plain links instead.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Uploaded another version

if (layout instanceof GroupLayout gl) {
for (MemoryLayout member : gl.memberLayouts()) {
checkHasNaturalAlignmentRecursive(member);
checkByteOrder(layout);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for uniformity, shoudn't this check be inside an if (layout instanceof ValueLayout) ... ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, will do.

Copy link
Contributor

@mcimadamore mcimadamore left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.

One (optional, for future?) thing that came to mind, is that if we wanted to speed up the check we could compute whether a layout is canonical or not on construction (since for structs we already have to go through all the elements and check alignment).

@JornVernee
Copy link
Member Author

@mcimadamore Thanks for the review!

I've created a CSR with the finalized javadoc here: https://bugs.openjdk.org/browse/JDK-8306631 Could you review that as well? TIA

@openjdk openjdk bot removed the csr Pull request needs approved CSR before integration label Apr 24, 2023
@openjdk-notifier openjdk-notifier bot changed the base branch from pr/13079 to master April 27, 2023 09:05
@openjdk-notifier
Copy link

The parent pull request that this pull request depends on has now been integrated and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork:

git checkout RejectPacked
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push

@openjdk
Copy link

openjdk bot commented Apr 27, 2023

@JornVernee this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout RejectPacked
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

@openjdk
Copy link

openjdk bot commented Apr 27, 2023

⚠️ @JornVernee This pull request contains merges that bring in commits not present in the target repository. Since this is not a "merge style" pull request, these changes will be squashed when this pull request in integrated. If this is your intention, then please ignore this message. If you want to preserve the commit structure, you must change the title of this pull request to Merge <project>:<branch> where <project> is the name of another project in the OpenJDK organization (for example Merge jdk:master).

@openjdk openjdk bot added the merge-conflict Pull request has merge conflict with target branch label Apr 27, 2023
@openjdk
Copy link

openjdk bot commented Apr 28, 2023

@JornVernee 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:

8303002: Reject packed structs from linker
8300784: Specify exactly how padding should be presented to the linker
8304803: NPE thrown during downcall classification under Linux/x64
8303524: Check FunctionDescriptor byte order when linking

Reviewed-by: 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 1 new commit pushed to the master branch:

  • f3c90f0: 8306711: Improve diagnosis of IntlTest framework

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
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.

@openjdk openjdk bot added ready Pull request is ready to be integrated and removed merge-conflict Pull request has merge conflict with target branch labels Apr 28, 2023
@JornVernee
Copy link
Member Author

/integrate

@openjdk
Copy link

openjdk bot commented May 1, 2023

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

  • 316d303: 8306851: Move Method access flags
  • a6b4f25: 8306825: Monitor deflation might be accidentally disabled by zero intervals
  • 2d7c507: 8305778: javax/swing/JTableHeader/6884066/bug6884066.java: Unexpected header's value; index = 4 value = E
  • e1b06ea: 8305780: javax/swing/JTable/7068740/bug7068740.java fails on Ubunutu 20.04
  • b54c4a3: 8299713: Test javax/swing/JTableHeader/6889007/bug6889007.java failed: Wrong type of cursor
  • b3dbf28: 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default
  • 6d6d00b: 8306954: Open source five Focus related tests
  • bb7608b: 8307088: Allow the jdbc.drivers system property to be searchable
  • a2d3fc8: 8304837: Classfile API throws IOOBE for MethodParameters attribute without parameter names
  • d43a5a2: 8307135: java/awt/dnd/NotReallySerializableTest/NotReallySerializableTest.java failed
  • ... and 27 more: https://git.openjdk.org/jdk/compare/b827ce8334c568d72990985ff6077db8334e2754...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label May 1, 2023
@openjdk openjdk bot closed this May 1, 2023
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels May 1, 2023
@openjdk
Copy link

openjdk bot commented May 1, 2023

@JornVernee Pushed as commit 1de1a38.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core-libs core-libs-dev@openjdk.org integrated Pull request has been integrated
3 participants