[Lldb-commits] [PATCH] D113521: Allow lldb to launch a remote executable when there isn't a local copy

Fri Nov 12 10:03:23 PST 2021

labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

In D113521#3125429 <https://reviews.llvm.org/D113521#3125429>, @clayborg wrote:

> I'm good with this to get things started. Pavel?

I think I mostly understand where's Jim's coming from, though I don't fully agree with the conclusions. But, it's not my feature, so...

In D113521#3125597 <https://reviews.llvm.org/D113521#3125597>, @jingham wrote:

> In D113521#3124239 <https://reviews.llvm.org/D113521#3124239>, @labath wrote:
>
>> Yes, that is the question I am asking. I didn't want to go off into designing an exec feature. I only mentioned because it seemed potentially related. We can put away that for now.
>>
>> While my question may not be "directly germane" to this patch, I wouldn't say it's orthogonal either. Right now (IIUC) the executable module is always the source of truth for the launch operation. Now you're adding a second source, so one has to choose how to handle the situation when both of them are present. You may not care what happens in that case, but _something_ is going to happen nonetheless. I guess we basically have three options:
>> a) prefer the executable module (this is what the patch implements, and it's also the smallest deviation from status quo of completely ignoring launch info)
>> b) prefer the launch info (that is what I proposed)
>> c) make it an error (I think that's something we could all agree on)
>>
>> The reason I proposed (b) is because of the principle of specific overriding general. The executable module is embedded into the target, so I would consider it more general than the launch info, which can be provided directly to the Launch method. Greg's use case (launching a remote binary that you already have a copy of) seems like it could benefit from that. However, maybe I have an even better one. What would happen with reruns? On the first run, the user would create a executable-less target, and provide a binary through the launch info. The binary would launch fine and exit. Then the user would try to launch again using the same target and launch info, but the code would go down a different path (I'm not sure which one) because the target would already have an executable. (This is actually kind of similar to the exec scenario, because the executable module would change between the two runs.)
>
> This is the same situation as if you had attached to a PID on a remote with no local binary, then reran, right?

I don't have an intuition for what should happen in that case, but I suppose it could work that way.

> That should also work w/o the user having to intervene with a LaunchInfo for the second run, and so should re-running in this case.  We shouldn't NEED the extra launch info to make rerun in your case work.

Yes, they don't NEED to provide it, but they CAN do so. If they provide the exact same information, then the situation would be as if they didn't provide anything. And I think that's your point here -- if the user provides the exact same path in the launch info, then he won't be able to tell the difference.
*However*, the user can also specify different launch info on the second launch. If he passes say, different environment (e.g., through SBTarget::Launch(SBLaunchInfo)), then these will take precedence over the ones stored in the target, right? Same for arguments, working dir, etc. But if the user specifies a different executable file, then it will be ignored.

I think I now understand how you look at this, but it this discrepancy still seems unfortunate...

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113521/new/

https://reviews.llvm.org/D113521