Skip to content
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

Move binary-symbols to another repo #38

Open
RyanGlScott opened this issue Apr 20, 2022 · 3 comments
Open

Move binary-symbols to another repo #38

RyanGlScott opened this issue Apr 20, 2022 · 3 comments

Comments

@RyanGlScott
Copy link
Contributor

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.

@RyanGlScott
Copy link
Contributor Author

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.

@kquick
Copy link
Member

kquick commented Oct 2, 2023

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?

@RyanGlScott
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants