-
Notifications
You must be signed in to change notification settings - Fork 26
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
Grand Theory of Unified Relocations #2
Comments
How "grand" are you thinking here? Would this include dynamic relocations? Would it include common assembler "fixups"? |
I think for starters, especially since dynamic relocations are out of scope for this crate, it would be good to focus only on linker relocation directives (although many dynamic relocations are actually simpler). I think this is what you mean by assembler fixups, although you might have something else in mind ? Basically I'm thinking we could devise a minor DSL/ declarative specification which indicates e.g. Where in a range of bytes to edit, how, what "type" (TLS, import/PLT, string/data reference, etc), and any other data we'd need. So the client would specify this as say an enum, and pass this into a single "relocations" vector, and then this library (or another crate if we want to make it more accessible) transforms those abstract relocations into concrete, platform dependent ones. Basically, it would be a relocation compiler for a relocation IR (ideally) |
Merge master with data linking fix
Going to paste my comment from another issue, as I think what I had in mind for this issue originally is best expressed so far by the proposal made there: #25 (comment) |
I want one relocation abstraction to rule them all. There are a number of ways to accomplish this, or perhaps, no good one way at all (in which case we have failed, but that's ok, don't worry!)
I'm opening this issue right now, but don't have a concrete proposal; experts, non-experts and all ideas welcome to chime in!
The text was updated successfully, but these errors were encountered: