JDevlieghere added a comment. In D121444#3375701 <https://reviews.llvm.org/D121444#3375701>, @labath wrote:
> In D121444#3375445 <https://reviews.llvm.org/D121444#3375445>, @JDevlieghere > wrote: > >> In D121444#3374854 <https://reviews.llvm.org/D121444#3374854>, @labath wrote: >> >>>> I wish I could make this distinction in the platform, but you need a >>>> connected process to do this. >>> >>> Basically, what you're saying is that the ArchSpec alone is not sufficient >>> to select the right platform. Instead of punching right through the layers, >>> could we just give more information (which I guess would be the system >>> architecture) to the functions responsible for selecting the right plugin? >>> Then they could do the regular ask-each-plugin-if-it-wants-to-handle-it >>> dance. The host plugin would say "I don't handle processes with >>> system-arch=*-ios" and then we would go around until we find the remote-ios >>> plugin saying "I live for debugging ios systems"? >>> >>> [I must admit that I have a bit of an ulterior motive for suggesting this >>> -- I also have a use case where the ArchSpec is not sufficient to select >>> the best platform, but I've struggled to formulate it in a way that makes >>> sense upstream. The system architecture is not relevant for my case (what >>> I'd really need is to inspect the details of the executable being debugged >>> -- mainly its path, but possibly also some other bits), but if we open the >>> door to more elaborate platform selection, then I might be able to squeeze >>> this in as well. >> >> Yup, that could totally work, it didn't seem worth like changing all that >> for just the one use case, but happy to do it if you can benefit from that >> as well. Did you have any particular design in mind? For me, passing an >> extra ArchSpec for the host arch would do the trick, but that doesn't get >> you much further. I could pass in a little context object which would hold >> an ArchSpec for the host arch and a FileSpec for your use case. Or maybe we >> should just pass in the process if we have one and get all the information >> from that. > > A process wouldn't help me, since I am primarily interested in the launch > scenario, where the platform is selected long before the process is launched. > I am contemplating passing in a ModuleSpec instead of a plain ArchSpec. That > would be sufficient for my use case, but I don't know if I really like it (it > seems somewhat strange because the we would really like to pass in the > process architecture, but a ModuleSpec would normally describe the module > architecture (which may be less precise)). So, it may be best to have a > specialized context object, but at the end of the day, I don't think that's > something that you need to solve. I think it would be sufficient to just add > an additional ArchSpec argument for now. If that idea proves itself (and I > decide to go ahead with this), I can upgrade that to a context object. Cool, that works for me CHANGES SINCE LAST ACTION https://reviews.llvm.org/D121444/new/ https://reviews.llvm.org/D121444 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
