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
Mach-O objects can contain a dyld info command that points to various data structures. Among those is the exports trie that stores the set of symbol names to be exported upon loading by dyld, if I understand things correctly. This particular structure can also be accessed to by looking for the LC_EXPORTS_TRIE load command.
Parsing such data is really not trivial, as it involves recursing through nodes and edges, so having it in object would be nice. Currently, the mach_object crate offers a correct implementation: I've been using it for a work project and it seems to behave well. However, this crate does not seem to be maintained anymore and the maintainer seems unreachable. We would therefore gladly work on porting the functionality to object instead and therefore upstream part of our work.
A few questions about the contribution then:
Does this even have its place in object?
What would go in machovs.read::macho? There aren't much definitions similar to the rest of macho, it's mostly the parsing algorithm that needs implementation.
Would it be desirable to add it to a higher-level API?
If so, should it be added directly onto MachOFile or to the Object trait and its implementation of it? Having it outside of the trait makes more sense to me because it would not be behavior common to all formats, but I'm just checking anyways.
The text was updated successfully, but these errors were encountered:
These three issues all seem reasonable, but I'm not at all familiar with these parts of Mach-O. A starting point would be to modify the readobj example to be able to display these data structures. This would be primarily using the low level API accessed via MachHeader, rather than MachOFile or Object. Adding a method to MachOFile too would be fine, but they probably don't belong in Object.
macho contains the raw file structures and constants. These are the things that you would find in a specification for the file format, and typically come from C header files. read::macho contains the code to do the parsing. This can include methods for the structures in macho.
Thanks for detailed answer! It is indeed consistent with what I had in mind. I should therefore be able to start working on this, some time soon hopefully.
Mach-O objects can contain a dyld info command that points to various data structures. Among those is the exports trie that stores the set of symbol names to be exported upon loading by
dyld
, if I understand things correctly. This particular structure can also be accessed to by looking for theLC_EXPORTS_TRIE
load command.Parsing such data is really not trivial, as it involves recursing through nodes and edges, so having it in
object
would be nice. Currently, themach_object
crate offers a correct implementation: I've been using it for a work project and it seems to behave well. However, this crate does not seem to be maintained anymore and the maintainer seems unreachable. We would therefore gladly work on porting the functionality toobject
instead and therefore upstream part of our work.A few questions about the contribution then:
object
?macho
vs.read::macho
? There aren't much definitions similar to the rest ofmacho
, it's mostly the parsing algorithm that needs implementation.MachOFile
or to theObject
trait and its implementation of it? Having it outside of the trait makes more sense to me because it would not be behavior common to all formats, but I'm just checking anyways.The text was updated successfully, but these errors were encountered: