Skip to content

New Attach/preattach - waitFor feature #13463

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
borjamunozf opened this issue Apr 6, 2025 · 1 comment
Open

New Attach/preattach - waitFor feature #13463

borjamunozf opened this issue Apr 6, 2025 · 1 comment
Labels
debugger Feature Request help wanted Can be fixed in the public (open source) repo.

Comments

@borjamunozf
Copy link

borjamunozf commented Apr 6, 2025

Feature Request

Hello!

I've rumbling a bit for certain scenarios where the target PID we want to debug crashes so early at startup, the process ends quickly before we can debug the initialization or we are interested only in the beginning of the execution.

Sometimes this could be tricky:

  • We cannot modify the source code for some reason.
  • The Launch debug could be really complex to setup.
  • Others

The debuggers like GDB or LLDB has not yet fully support for this kind of stuff:

  • GDB has this in the roadmap.
  • LLDB has something similar but only works for MacOSX (as far as I know)

So I've working a few hours in a naive & simple waitFor approach (Linux only) with basic polling, I think it could work and be useful to handle this scenarios.

The current idea or approach is something like this:

  • New options for Attach mode: waitFor object with three properties
  • Enabled: specifies to use waitFor attach support.
  • Pattern: process name pattern (finds in PID detail if this pattern is included in the string process detail)
  • Timeout: time to wait for process match in Ms.

Snippet:

"waitFor": {
   "enabled": true,
   "pattern:" "myprocessnamepattern",
   "timeout": 10000 
}

Overall, something that I'm interested in -and probably others- is to "Preattach". Even if we wait for the PID and attach early, if the app is huge the debugger will take time to load symbols (in our case, even using .gdbindex could take up ~15-20seconds in large C++), so we will miss again the startup of the program!

The options here:

  1. SIGSTOP the process by default. This would require some GDB setupCommands, for example, regarding the signal handle and so on.
    1.1) If we SIGSTOP, perhaps find a way to execContinue after attaching, but I guess that this is not really doable from the Extension, right? We don't know exactly when the debugger has really completed the initialization from the Extension.

  2. Allow a new json key for waitFor like stopAtEntry idea.

  3. ?

I could do the PR with my current code in Draft if you consider this feature to be interesting and valuable for the extension.
Thanks!

Copy link

Thank you for your feature request. While we may not be able to implement it immediately, we will monitor community reactions to see how it fits into our backlog. Additionally, if you're working with GDB/LLDB, please note that the code is open source at https://github.com/microsoft/MIEngine/wiki/Contributing-Code . Your contributions are always welcome and appreciated.

@github-actions github-actions bot added the help wanted Can be fixed in the public (open source) repo. label Apr 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
debugger Feature Request help wanted Can be fixed in the public (open source) repo.
Projects
None yet
Development

No branches or pull requests

2 participants