JDevlieghere added a comment. In D62500#1518815 <https://reviews.llvm.org/D62500#1518815>, @labath wrote:
> Definitely go for the option of refactoring the DYLD AuxVector class to make > it usable from lldb-server. +1 > It doesn't look like it should be that complicated even. Instead of passing > it a `Process` instance, we can just pass it the data we have obtained from > the right process (liblldb process, or lldb-server process), along with any > other data it needs to interpret it (looks like it's just the pointer size > (?)). > > The question of plugins depending on each other is just a matter of finding > the right place to put this new class. In my mind, Plugins/Process/Utility` > is not a real plugin, and I don't see much of a problem in the Posix dynamic > loader depending on that (it makes sense that it would need *some* data about > the process in order to do its job. Or, given that the new class will depend > on just the data extractor and nothing else, we could put it all the way up > to `Utility`. I don't think this is general enough to fit in `Utility`. Looking at other classes in `Plugins/Process/Utility`, it seems like a better fit. > A third option would be to create a completely new library for this. In the > past we've talked about a new library for "classes describing various > properties of a process", where we'd have MemoryRegionInfo, ProcessInfo, etc, > but so far it hasn't materialized. It seems like this could fit nicely into > this description, so we could start with the new library with this class. > +@JDevlieghere for any thoughts on this. Do you mean having `AuxVector` in this library, or having it take a `ProcessInfo` instead of the `Process` itself? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62500/new/ https://reviews.llvm.org/D62500 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
