I'm experimenting with writing a dynamic linker for Mach-O binaries and running into difficulty with accessibility of context needed for processing load commands. For example, a SegmentCommand32 provides sufficient information to reserve memory, but fetching the raw bytes to load into memory requires returning to the bytes fed into the parser. More significant, however, is being unable to directly access section data related to a segment. Doing so would require separately iterating the segments field of the MachO to find a matching segment , even though that field is populated from the same data as load_commands.
I propose something like having the various command structures privately hold onto the necessary context (raw data and parsing context) needed to expose related data as functions in the impl, e.g. something like the following:
impl SegmentCommand32<'_> {
pub fn sections<'a>(&'a self) -> Section32Iterator<'a> {
Section32Iterator {
data: self.data,
count: self.nsects as usize,
offset: self.offset + Segment::size_with(&self.ctx),
idx: 0,
ctx: self.ctx,
}
}
}
Likewise, DylibCommand could offer a name() function, SymtabCommand a symbols() function, etc. In addition to making this information more accessible by iterating the load commands, it would mean this information could be had as iterators on the main MachO object via filtering rather than additional Vecs which may lack the context to use them.
This is just one idea for localizing the information to be useful for a dynamic linker, but I'm open to other suggestions for how this could be implemented.
I'm experimenting with writing a dynamic linker for Mach-O binaries and running into difficulty with accessibility of context needed for processing load commands. For example, a
SegmentCommand32provides sufficient information to reserve memory, but fetching the raw bytes to load into memory requires returning to the bytes fed into the parser. More significant, however, is being unable to directly access section data related to a segment. Doing so would require separately iterating thesegmentsfield of theMachOto find a matching segment , even though that field is populated from the same data asload_commands.I propose something like having the various command structures privately hold onto the necessary context (raw data and parsing context) needed to expose related data as functions in the
impl, e.g. something like the following:Likewise,
DylibCommandcould offer aname()function,SymtabCommandasymbols()function, etc. In addition to making this information more accessible by iterating the load commands, it would mean this information could be had as iterators on the mainMachOobject via filtering rather than additionalVecs which may lack the context to use them.This is just one idea for localizing the information to be useful for a dynamic linker, but I'm open to other suggestions for how this could be implemented.