You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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)
pchickey
pushed a commit
to pchickey/faerie
that referenced
this issue
Dec 13, 2017
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: