Description
I've been thinking about refactoring the initialize and address_finder code to make it easier to test, fully migrate to goblin where we can (#50), etc. py-spy has a cleaner and more mature solution to the problems that those modules solve. Maybe we could share more code?
There was an earlier effort in this direction (#180) that seemed healthy for both projects.
Things that seem straightforward to share:
- Code for locating binaries, shared libs, etc. (PythonProcessInfo)
- Version detection and parsing (varies only by symbol name?)
- Code that uses goblin to parse binaries (binary_parser.rs)
- Containerized environment handling
And maybe also:
- Irregular sampling interval logic
- Top-like viewer
- Trait for stack traces
- Visualization
The first group falls under a kind of "process info discovery" umbrella that doesn't vary much between the projects. We need to find different symbols for ruby vs. python, but the code for finding them—and dealing with any OS quirks—could probably be the same. My plan has been to build a RubySpy struct (based on PythonSpy) and see what happens. I'm hoping to get a first version of that working this week. Much of the work has effectively been s/python/ruby, which seems promising.
Does factoring out a spytools crate still feel like a good move? Should they be a set of smaller, more focused crates instead? Could these responsibilities be moved from py-spy into remoteprocess? (I'm open to suggestions!)
cc @benfred