Conversation
A native image has no linker in it. Every downcall stub is machine code written while the image is being built, and the builder can only write the ones it was told about, because a function descriptor here is assembled out of ordinary objects at run time and there is nothing in the bytecode to read it off. Told nothing, an image builds clean and dies on the first query. So both artifacts carry their own metadata. zudb-ffm lists every signature it binds and zudb-native registers the libraries, so that a platform's library ends up inside the image rather than being looked for on a machine that has never had one installed. The list is not maintained, it is derived. Forty-odd entries nobody reads, one of them stale, is exactly the failure this is supposed to prevent, so every binding registers its shape as it is made, a test writes out what that comes to, and the build fails if the file in the repository says something else, with the file that would have been right sitting in target/. Adding a function to the C ABI therefore either changes nothing here, because its shape is one of the forty already listed, or fails loudly with the answer attached. That test can only say the file matches the binding. Whether it is the file the image builder wanted is a thing only an image can answer, so CI builds one on Linux and macOS and makes it run a query, with no property, no environment variable and the library coming out of the image.
The image builder reads canonical layouts, the ones Linker.canonicalLayouts answers to, so a pointer is void* and not pointer. It said so, on the first native image anyone has built of this. long long rather than long for a 64-bit integer, and that is not pedantry: C's long is four bytes on Windows and eight everywhere else, and this file is written once and read on all of them.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A native image has no linker in it. Every downcall stub is machine code written while the image is being built, and the builder can only write the ones it was told about, because a
FunctionDescriptorhere is assembled out of ordinary objects at run time and there is nothing in the bytecode to read it off. Told nothing, the image builds clean and dies on the first query.Both artifacts carry their own reachability metadata now.
zudb-ffmlists every signature it binds, andzudb-nativeregisters the libraries so that a platform's library ends up inside the image rather than being looked for on a machine that has never had one installed. A classifier is the right dependency for an image, since the platform-complete jar would put seven libraries in it and use one.The list is not maintained, it is derived. Forty-odd entries nobody reads with one of them stale is exactly the failure this is meant to prevent, so
Shapesremembers every shape as it is bound,ReachabilityTestwrites out what that comes to, and the build fails if the file in the repository says something else, with the file that would have been right sitting intarget/and the assertion message saying so. Adding a function to the C ABI therefore either changes nothing here, because its shape is one of the forty already listed, or fails loudly with the answer attached.Sorted rather than in binding order, so the file is the same file however
Abi's constructor is rearranged and a diff on it is about what changed rather than about what moved. The two critical bindings get their own entries, because a stub for a critical call is not the same machine code as a stub for an ordinary one even where the signature is identical.That test can only say the file matches the binding. Whether it is the file the image builder actually wanted is a thing only an image can answer, so CI builds one on Linux and macOS and makes it run a query, with no property, no environment variable, and the library coming out of the image. The metadata schema is the one place here I could not check locally, since there is no GraalVM on this machine, which is exactly why that job exists.