[BitFlipper]

Thanks, that worked.

I did find that using gdb on Windows with the so files copied locally ended up being substantially slower than setting up gdb + gdbserver on the same host (so both running on the same host). That is also much faster than using the gdb that comes with that host directly, since it is quite old. But copying a newer gdb to the host and then running it via gdbserver seems to work the best.

[BitFlipper]

There was an email saying there was some sort of error with the order, error LME763472. The payment went through so I have no idea what the issue is. I forwarded that email to sales@sysprogs.com as well as support@sysprogs.com.

[BitFlipper]

I just renewed my license.

[BitFlipper]

Thanks for the info.

I guess then the only option is to use the Custom Project Wizard to create projects that are as close as possible to the non-VC++ ones I created previously. I will attempt to re-use the CMake files from those previous projects.

[BitFlipper]

OK thanks, I will follow those steps next time and see if I can resolve the path mappings easier.

Somewhat related…

I believe I tried to use a VGDB user variable that was previously set via a Custom Debug Step in the Additional GDB Commands window, e.g:

set substitute-path $(ResolvedSymlinkPath)/foo /bar

However this did not work AFAICT.

Do you believe this could work if I set an env var under Debug settings -> Environment from the captured user variable from the Custom Debug Steps, and then instead do:

set substitute-path ${ResolvedSymlinkPath}/foo /bar

I’m going to try that regardless but it is sometimes hard to tell what GDB is doing with the paths.

[BitFlipper]

Excellent, thanks for the new build! I just tried it and it solved both issues I mentioned! Looks like they were related in some way.

BTW, seeing that I have had this behavior for a long time now, I forgot that VGDB will switch to the VGDB Output window, which is actually fine now that it is working again for me. Previously it would switch to either the GDB Session or SSH Console, and stay there. I had to manually switch back to the Output window.

Regarding the windows, most likely you close the GDB session or the output window at some point, instead of just leaving it in the background. Due to the way VisualGDB handles it, it needs to re-create the window when it becomes relevant, bringing it into focus. Simply keeping it open in the background should work as long as you have the automatic window activation disabled. If not, please try determining a reliable set of steps to reproduce the issue so that we could try reproducing it on our side.

No I always left all windows open. They were all still open at the time when I started the next debugging session. This included all VGDB specific windows as well as the main Output window, and any other window that were open.

I did a quick check by disabling the new option again… It appears that after the Source Not Available window is shown, and then pressing F5 to run, VS will switch to the tab of whatever is the very last open window, instead of the VGDB Output window.

Whatever the issue in that regard, it seems to no longer occur when I set the new option to False. So thanks again for the that new option!

• This reply was modified 3 years ago by BitFlipper.

[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.

[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!

[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]

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.

[BitFlipper]

Hi,

This works great, thanks for adding this feature so quickly! I like that it auto-populates with all loaded symbol files. This makes it really easy to select just the needed ones. The time displayed to load each file is also a great help!

Thanks again!

[BitFlipper]

So the asm break turns out to be not so useful as I ran into all sorts of weird problems. I have another solution that is mostly working now, except for one non-critical but annoying issue. Maybe you have some insight on how to fix that last issue. What I have is:

Do:

set auto-solib-add off
handle SIGUSR1 stop noprint nopass

 

Somewhere in my code, do:

  raise(SIGUSR1);

 

Have an external GDB command file containing something like this:

catch signal SIGUSR1
commands
echo Now handling SIGUSR1
sharedLibrary myLib1.so
sharedLibrary myLib2.so
end

 

Add the following to “Additional GDB Commands”:

source /path/to/gdb_cmd_file

The above works and is quite fast to start up. But the remaining issue is that it breaks and stops on the raise(SIGUSR1); I guess that is to be expected. However I would like to just let it continue automatically after it handled the SIGUSR1. So when I then add the following continue to the commands in the file:

handle SIGUSR1 stop noprint nopass
catch signal SIGUSR1
commands
echo Now handling SIGUSR1
sharedLibrary myLib1.so
sharedLibrary myLib2.so
continue
end

 

…it causes VS to lock up, although I can see the program ran successfully and exited. At that point I need to force kill VS. I think VGDB still thinks the program is stopped, although it ran to completion.

Any suggestions on how to get it to work?

Thanks for you help!

• This reply was modified 4 years, 6 months ago by BitFlipper.
• This reply was modified 4 years, 6 months ago by BitFlipper.

[BitFlipper]

Thanks for the quick reply! For each of the suggested tricks:

1. I did a quick test of the asm break, and that works and is very fast after first doing set auto-solib-add off. After it hits the breakpoint, I can then do sharedLibrary on the libs I care about (which also loads quite fast).
   I’m wondering if I can automate this. For instance, if I put the asm break somewhere early on in my executable (let’s say in its startup code), then have a Python script that responds to that break. It then does gdb.execute(“sharedLibray <mylibs>”) and continues. So it is basically transparent.
2. I tried setting a breakpoint using the function name but I could not get it to work.
3. Where can I send a log file? I don’t want to post it here publicly. It would be great if VGDB allowed you to create a whitelist/blacklist that can be used to control symbol loading. I’m surprised it is so hard to do with GDB, or maybe I’m just missing something.
4. Previously I was looking into GDB index files a bit to see if that could help. But the above asm break seems the best short term solution, so I’ll try to make that work.

Thanks for your support!

[BitFlipper]

Excellent, that seems to have fixed the issue!

Thanks 🙂

[BitFlipper]

Hi,

Thanks that worked, however now the problem is that right after debugging ends, a second (albeit blank)  VisualGDB Remote Console window is opened next to the original one and made active. I need to close this second window each time.

Thanks

[Author]

Posts