Selective debug symbol loading: New Instance vs Attach

[BitFlipper]

Hi,

Thanks for adding the feature to selectively load debug symbols. This helps a lot in my scenario where some libraries can take over a minute to load (issues outside of my control).

However this only seems to work when I use the New Instance debug mode, but not for the Attach debug mode. I’m not talking about the Attach To dialog, I’m talking about the mechanism where I configure VGDB to read the pid into AttachPID from a remote file’s contents (this part works).

After attaching though, none of the debug symbols are loaded. The configuration is essentially identical to the configuration where it starts a new instance (same path mappings etc). In fact the Attach configuration was originally copied from the New Instance configuration.

If I add set auto-solib-add on to Additional GDB Commands, the symbols are indeed loaded successfully and breakpoints work properly, however this takes FOREVER so it isn’t practical to do it that way. It seems it is all or nothing when attaching.

Is there a way to make the Attach mode also only load symbols for the selected symbol files?

I have a few additional questions…

1. When attaching to a running process, it would be nice if the debugger did not stop, but instead keeps running. I tried enabling non-stop mode but this did not make a difference. Is there a way I can make it not stop when attaching?
2. Other than editing the vgdbsettings file directly, is there a way to remove stales entries from the list of auto-detected libraries?

Thanks in advance!

• This topic was modified 3 years, 9 months ago by BitFlipper.

[support]

No problem, please try this build: VisualGDB-5.5.8.3740.msi. It will handle the symbols correctly when attaching.

You can disable the initial stop when attaching to processes by using the Debug->Attach to Process command. The dialog shown when pressing the “Find” button will display an option to suppress the initial stop.

 

[BitFlipper]

Hi,

I tried the the new build and it seems to work as far as the symbol loading goes (thanks!).

However, while the Debug->Attach to Process method of attaching does indeed run without stopping (I verified it on my side), it is the other method of attaching that I can’t get to attach without stopping.

What I mean is how one can configure it under Debug settings -> Debug mode -> Attach so it attaches to a specific process using the AttachPID value that was retrieved from a file’s contents using a custom debug step. When I now press F5, it does indeed attach to the running process, however it stops and I need to press F5 again.

Also, I’m not 100% sure since I only tried it once, but it almost seems now as if the Debug settings -> Debug mode -> New Instance of debug mode now ALSO stops, where before I did the upgraded to the the new build, it never stopped after pressing F5.

Thanks for your support!

• This reply was modified 3 years, 9 months ago by BitFlipper.

[support]

No problem, we have added a checkbox to ignore the initial stop to the Debug Settings->Debug Mode view. Please try this build: VisualGDB-5.5.8.3742.msi

We also added support for deleting the stale entries from the symbol list by pressing the “Delete” key.

[BitFlipper]

Thanks for the quick response – excellent customer service, and very much appreciated!

I have not had a chance the test out the attach-without-stop option yet as I’m currently dealing with a build breakage. I will let you know once I try it out and if I run into any issues.

[BitFlipper]

I have confirmed that the Debug settings -> Fully Custom-> After connecting to target -> Start target with the “run” command way of starting the process now also stops, where previously it did not.

I edited the *.vgdbsettings file and added <NoInitialStop>true</NoInitialStop> under <LaunchGDBSettings> but this did not fix the problem (in fact it just gets removed the next time one edits the settings).

Is there a way I can change it to the previous behavior so it doesn’t stop when starting a new process?

Thanks again for your great support!

[support]

Sorry, we could not reproduce the stop with the Start target with the “run” command. Most likely, something on the gdb side is causing the stop. Please try examining the GDB output by switching the GDB Session window to All GDB Interaction mode.

[BitFlipper]

It appears this only happens if you have a breakpoint set somewhere before you start the run. If no breakpoints are set, it runs and exits the program without stopping.

If I do have a breakpoint set and start the run (F5), it stops in main, even though “Stepping into new instance (F10) will stop in: …” is unchecked. It never used to behave this way before, no matter how many breakpoints I had set.

So maybe the way to help repro it is to set other breakpoints before pressing F5.

Let me know if you need any additional info from me.

[support]

OK, as it looks like something very rare and specific, the easiest way to us to narrow it down would be if you could share the exact steps to reproduce it on our side.

Please try creating a new project completely from scratch, make sure the problem still exists, and then share the complete steps we could follow on our side to reproduce it.

[Author]

Posts