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
Conversation
Co-authored-by: Paul Sandoz <paul.d.sandoz@googlemail.com>
Co-authored-by: Paul Sandoz <paul.d.sandoz@googlemail.com>
👋 Welcome back jvernee! A progress list of the required criteria for merging this PR into |
@JornVernee |
@JornVernee |
@JornVernee The following label will be automatically applied to this pull request:
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. |
84cb655
to
e11fc6b
Compare
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 |
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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: |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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) ...
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, will do.
There was a problem hiding this 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).
@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 |
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 |
@JornVernee this pull request can not be integrated into 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 |
|
@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:
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
Please see this link for an up-to-date comparison between the source branch of this pull request and the ➡️ To integrate this PR with the above commit message to the |
/integrate |
Going to push as commit 1de1a38.
Your commit was automatically rebased without conflicts. |
@JornVernee Pushed as commit 1de1a38. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
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
Issues
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