labath added a comment. 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. 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
