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
binary-symbols is a general-purpose library for describing symbols in binaries, which makes its placement in flexdis86 (ostensibly an x86-specific library) somewhat confusing. We should move binary-symbols to a different home to reflect its broader scope.
The text was updated successfully, but these errors were encountered:
It would also be nice to make elf-edit depend on binary-symbols. Both libraries independently define their own type SegmentIndex = Word16 type, but we ought to consolidate this into a single definition.
It seems like a good portion (SymbolIdentifier, SegmentIndex, SectionIndex) of binary-symbols reference ELF-specific things; should those move to elf-edit or be part of the standalone?
Some of these concepts could reasonably apply to other file formats—for instance, PE on Windows also has notions of sections and symbols. But your point is well taken: it's not entirely clear what should go into elf-edit versus a separate library like binary-symbols. The flexdis86 library itself (from which binary-symbols was spun out) doesn't depend on elf-edit, so perhaps a crude answer to this question is "things that are shared between flexdis86 and elf-edit". There is probably a more principled way to categorize things, however.
binary-symbols
is a general-purpose library for describing symbols in binaries, which makes its placement inflexdis86
(ostensibly an x86-specific library) somewhat confusing. We should movebinary-symbols
to a different home to reflect its broader scope.The text was updated successfully, but these errors were encountered: