Feat: naive waitFor preattach/attach support

[borjamunozf]

Hello :)

Coming from this #13463 thread where I explain a bit the aim and context, but to sum it up:

• Support naive early attach / preattach for scenarios where the target debugee crashes before attaching, the initilization phase already took place or the aim to get full visibility of the init launch of the process.
• It's not that weird to have this kind of problems and challenges, so a preattach functionality could be really useful when the Launch mode is really complex to setup or the actual code is not feasible to be modified and just put sleep or pauses.

This is a naive approach I came up with, but tested with success in our C++ codebases for the company I'm working on.

• Polls the /proc (Linux support only) and waits for the pattern match PID detail.
• Sends SIGSTOP.

The SIGSTOP, as I mentioned in #13463, is something that could be optional or specified as key for the waitFor properties. but at least for decent size C++ code the symbols loading and debugger startup (be LLDB or GDB) could be slow ~15-20secs, so we need to SIGSTOP and handle that in GDB side.

I'm not a Typescript dev at all, probably there's some work and room to improvements, but I think is a decent step to propose here and discuss with you if you're up to include as functionality.

There's pending changes to apply, but I preferred to upload the current status and continue if you're interested.

Thanks!

[borjamunozf]

@microsoft-github-policy-service agree

[fearthecowboy]

I like the idea of this - I think we'd need to make sure this was working for all platforms.

I'm a bit nervous about how to make the polling robust as possible (and available across the platforms) - the looping around grabbing the processes is a bit of a wide-casting net (getting all the processes and then parsing the results) - we should probably make it so that we're only asking PS for the processes that are likely matches (but that complicates things with just having an expression obviously)

We'd need another way to suspend the process on Windows (given the lack of SIGSTOP). Not impossible.

I had been thinking a while back if a script launched before debugging might be another way to go to do this - If a task was created to poll in a loop and suspend the matched process, but then we'd still need to have the editor know when to start attaching.

I'll bring it up with some other folks and see what they think.

[sean-mcmanus]

I don't think it necessarily needs to work on Windows, as long as the user can find out that it's not supported. Others might disagree though.

[bobbrow]

RE: avoiding polling
It may be possible to monitor the /proc folder for new processes and check the exe entry of a new processid folder against the program you're waiting for.

I also don't think Windows parity is required. We could support it for cppdbg without supporting cppvsdbg.

[borjamunozf]

RE: avoiding polling It may be possible to monitor the /proc folder for new processes and check the exe entry of a new processid folder against the program you're waiting for.

I also don't think Windows parity is required. We could support it for cppdbg without supporting cppvsdbg.

Indeed, the /proc polling is the approach I'm more fond of if you think Linux only support is ok, at least for now .
I started with that approach , but after that I switch to what the others _attachers were using (ps analogous) to be as close as possible and think I mixed the comments/idea out.

[bobbrow]

Indeed, the /proc polling is the approach I'm more fond of if you think Linux only support is ok, at least for now . I started with that approach , but after that I switch to what the others _attachers were using (ps analogous) to be as close as possible and think I mixed the comments/idea out.

I think I spoke too soon. cppdbg is meant to work on Windows as well, and we want to have a consistent experience across all platforms, so we probably don't want to maintain 3 different implementations each doing things differently. Polling shouldn't be too bad since it would start shortly before the process is launched. As long as there's a timeout, it should be ok.