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

stage2: wasm-linker - Place decls in the correct segment and order segments #11933

Merged
merged 2 commits into from Jun 25, 2022

Conversation

Luukdegram
Copy link
Sponsor Member

Previously, all decls would be placed within the 'rodata' segment regardless of constness. With this change, we correctly put them into segments such as 'data' and 'bss'. The linker now also orders the segments in such a way to always place the bss segment last, which allows us to completely omit this segment in the case where the memory is exported and not imported from the runtime. This allows smaller binaries as the runtime itself will zero-initialize the memory for us.

Decls will now be put into their respective segment.
e.g. a constant decl will be inserted into the "rodata" segment,
whereas an uninitialized decl will be put in the "bss" segment instead.
We now ensure the "bss" section is last, which allows us to not
emit this section and let the runtime initialize the memory with 0's instead.
This allows for smaller binaries.
The order of the other segments is arbitrary and does not matter, this may
change in the future.
@kubkon
Copy link
Member

kubkon commented Jun 25, 2022

Previously, all decls would be placed within the 'rodata' segment regardless of constness. With this change, we correctly put them into segments such as 'data' and 'bss'. The linker now also orders the segments in such a way to always place the bss segment last, which allows us to completely omit this segment in the case where the memory is exported and not imported from the runtime. This allows smaller binaries as the runtime itself will zero-initialize the memory for us.

Do you overwrite the entire file on every flush per incremental update? If not, ensuring correct order for segments may require selectively moving segments in file (via copyRangeAll or related) if a Decl grows over the segment's size, etc. But if you wipe the entire file and write to it from scratch on every flush, this is obviously not an issue :-) I'm asking since this is what I have to deal with with MachO and to some extend Elf (as far as .bss and TLS will go).

@Luukdegram
Copy link
Sponsor Member Author

Do you overwrite the entire file on every flush per incremental update? If not, ensuring correct order for segments may require selectively moving segments in file (via copyRangeAll or related) if a Decl grows over the segment's size, etc. But if you wipe the entire file and write to it from scratch on every flush, this is obviously not an issue :-) I'm asking since this is what I have to deal with with MachO and to some extend Elf (as far as .bss and TLS will go).

The entire file indeed gets overwritten in its entirety during flush.

@kubkon
Copy link
Member

kubkon commented Jun 25, 2022

Do you overwrite the entire file on every flush per incremental update? If not, ensuring correct order for segments may require selectively moving segments in file (via copyRangeAll or related) if a Decl grows over the segment's size, etc. But if you wipe the entire file and write to it from scratch on every flush, this is obviously not an issue :-) I'm asking since this is what I have to deal with with MachO and to some extend Elf (as far as .bss and TLS will go).

The entire file indeed gets overwritten in its entirety during flush.

Gotcha, thanks for clarifying!

Copy link
Member

@kubkon kubkon left a comment

Choose a reason for hiding this comment

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

Awesome work!

src/link/Wasm.zig Show resolved Hide resolved
@kubkon kubkon merged commit 08459ff into ziglang:master Jun 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants