Link basic MachO executables with stage2 #6476
Conversation
kubkon
added
os-macos
frontend
|
Exciting stuff! 👍 |
|
OK, so I think this is ready for review. |
* Convert draft to generate all relevant segments and sections in right places * Do not prealloc space in text blocks until we can NOP * Write out LC_LOAD_DYLINKER command * Add LC_LOAD_DYLIB command in order to specify to load libSystem * Redo update decl exports (similar to Elf globals, globals need to be contiguous in memory)
Also, rewrites codegen section to store symbol address in a register to then later invoke `callq` on the register.
This commit refactors free space analysis (and VM analysis) somewhat. This is still far from perfect, but at least it's not using any hardcoded values. This commit also reorganizes different flushing bits here and there, so that bit common to Exe and Obj are put in the common path, while Exe-specific are behind an appropriate switch/if statement.
| \\} | ||
| \\ | ||
| \\fn print() void { | ||
| \\ asm volatile ("syscall" |
There was a problem hiding this comment.
I'm on board with using this for now in the early stages of development, but the end goal here is to use libSystem for calling write() and exit() right?
Also the plan for the entry point on macos is to expose main() instead of _start:
Line 26 in 302a69f
There was a problem hiding this comment.
Excellent point. Currently, this won't work since I've got the export trie hardcoded to only encode the _start symbol; however, I'm working on an actual mechanism for auto-generating it from global exports as we speak.
No, I don't think so. Or put it another way, I haven't tested it yet, plus I'm still working on the incremental linking bit. But soon... 😈 |
This PR adds enough of MachO linker implementation to pass basic stage2 "Hello, world!" test.
A couple of things left before I'll feel happy about merging this in:
- [ ] add basic export trie generation algorithm - currently, this bit is 100% hard-codedEDIT: I really want this merged and working out a good algorithm for export trie will take some time (and potentially changes to the current codebase anyhow), so I'm inclined to leave it as is, i.e., it currently assumes that
_startsymbol is there and is the only exported symbol. In terms of free space analysis, I'm still not 100% happy with how things are done, but after more refactoring, it's definitely better than it was, and in subsequent PRs I'll revisit this bit and see if I can come up with a better alternative to how it's done now. Oh, and this mainly applies to Exes since Objs are a lot simpler in MachO wrt segment/section(s) organisation.