-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
elf: more incremental progress #21629
Conversation
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.
Upon closer examination, I don't think the frontend should be changed at all with regards to the cache. Instead, the linker should detect file metadata (size, inode, mtime, hash) upon first load of any given file, and with each update, detect if there have been any changes since the last update. The linker needs to always produce a correct output file no matter what changes have occurred. It can redo as much linking as necessary to accomplish this.
src/Compilation.zig
Outdated
hash.add(obj.loption); | ||
} | ||
for (comp.c_object_table.keys()) |key| { | ||
hash.addBytes(key.status.success.object_path); |
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.
This will always access the wrong union field.
Sounds good. So the most effective way of accomplishing this would be to serialize this and save to state and then restore from the said state, do I understand this right? |
This way we can track if we need to redo the object parsing or not.
When resolving and writing atoms to file, we may add dynamic relocs to the output buffer so clear the buffers before that happens.
I rebased, removing the cache management stuff. Now I'll work on adding some commits to demonstrate the strategy I have in mind for this. |
Nice, looking forward to it! |
In order to track if we need to reparse paths and objects (including relocatables, archives and shared objects) I've decided to add the paths, files, and some flags to local cache but I haven't used the frontend mechanism to achieve this, well not yet anyhow since I wasn't sure how to best go about it. I would appreciate input on this especially from @andrewrk and @mlugg. Next in order to detect if we are running the link from scratch (i.e., if we should invalidate the cache) I'm committing a random uuid-like value for the linker run. Again, this is very much a PoC so any feedback and suggestions are more than welcome.
Now onto progress report. I hear from @mlugg that apparently with this patch incremental works enough to do some basic incremental updates on Andrew's tetris clone. I have also managed to get a simplistic update to building zig itself working too. Now, we are from incremental being actually usable but it's (some) progress.