Add a 'can_connect' parameter to Process plugin initialization, and use
it to filter plugins to these capable of remote connections. This is
used to prevent 'process connect' from picking up a plugin that can only
be used locally, e.g. the legacy FreeBSD plugin.
Details
Diff Detail
Event Timeline
This is all weird (not in a "your fault" way). ProcessFreeBSD is decidedly a local-only plugin. It could never successfully complete the "process connect" command, regardless of whether we have some other remote plugin or not.
I think that the real fix here would be to change the plugin selection logic (Target::CreateProcess) to convey the fact that we're looking for a connectable plugin. The method already contains a FileSpec *core_file argument, which I guess is needed to select the proper core file subclass, so adding a can_connect argument would not be unreasonable (though not exactly pretty either).
Though, for the purposes of this test, just adding a "--plugin gdb-remote" argument to the "process connect" command should be sufficient as well.
It might, though I am not sure how would you make that interact with the current selection logic. And I think you'll still need to pass a flag all the way to Process::FindPlugin, as that's the thing which iterates over registered classes.
Seems ok. The code could really use a refactor though...
lldb/test/Shell/Commands/command-process-connect.test | ||
---|---|---|
1–2 | I'm pretty sure windows suffered from the same problem. |
lldb/test/Shell/Commands/command-process-connect.test | ||
---|---|---|
1–2 | Ok, I will remove this and see what buildbots say. |
I'm pretty sure windows suffered from the same problem.