You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
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:
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.
Allow a new json key for waitFor like stopAtEntry idea.
?
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!
The text was updated successfully, but these errors were encountered:
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.
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:
The debuggers like GDB or LLDB has not yet fully support for this kind of stuff:
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:
Snippet:
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:
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.
Allow a new json key for waitFor like stopAtEntry idea.
?
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!
The text was updated successfully, but these errors were encountered: