forked from HaxeFoundation/neko
-
Notifications
You must be signed in to change notification settings - Fork 0
Get latest changes from HaxeFoundation/neko #1
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
Merged
Conversation
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
Enable FreeBSD builds
executables made via 'nekotools boot <bytecode>' on Linux systems (really systems using ELF ABI) will be irreprably damaged if stripped by the 'strip' toolchain program. The issue is described in detail here... #75 The solution here is to modify the Neko VM and the nekotools programs to be more ELF-aware. This new code is activated by compiling with ABI_ELF (now the default for Linux builds). The Neko VM will now attempt to find a '.nekobytecode' section in the executable by rifling through the ELF section headers. If such a section is found, it is inspected, looking for the customary bytecode signature at the end of the section. If the section is not found, the code will fall back to the old algorithm and search at the end of the file. (This algorithm was necessary since tools like strip may actually place other sections after the bytecode at the end of the file, even if the bytecode section was initially at the end of the file.) Additionally, the 'nekotools' executable now understands how to inject bytecode into the '.nekobytecode' section, resizing that section as appropriate. This allows this data to survive strip attempts. Below are some measured performance and executable size impacts of these changes as measured on my Fedora Core 17, x86_64 box that uses Xeon processors... perf : 'neko -version' execution slowed by 32% or ~4.4ms/execution on my 2.53Ghz Xeon perf : 'nekoc -help' execution slowed by 4% or ~13.8ms/execution on my 2.53Ghz Xeon size : neko vm grew 2,880 bytes or ~23% larger; still under 16KB size : nekotools boot executables can be stripped now, making them 2%-8% smaller on x86_64
project files. I am unable to test this, but it seems right. I'll let AppVeyor check it for me.
interpreter into libneko. Move bytecode injection logic into std.ndll where it belongs so that it can be visible to nekoboot.neko. Also, adjust symbol exposure of elf helper functions in libneko so that they are properly accessible on Windows (hopefully).
Fix strip issue with 'nekotools boot' created executables on Linux ELF...
disable the ELF stuffs for OSX
ppenzin
added a commit
that referenced
this pull request
Sep 4, 2015
Get latest changes from HaxeFoundation/neko
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.