Several questions on remote linux debugging

[Zoellick]

Hello!

I’m using Visual GDB for 2 purposes: building fairly large solution with 30+ projects using boost build system and attaching to application for debugging.
A build process performs as i expect.

Things are different with debugging. The only possible scenario for me is to attach to an already started application.

Here are some related questions:

1. Is it possible to perform any gdb command on session start up? My case is necessity to perform “set debug-file-directory” as i need to strip the debug info from the main executable and store it separately on debug machine.
2. I use “attach to process” debugging, hence Visual GDB has no chance to guess which project I’m actually debugging.
   All .vgdbsettings related to path mapping are left unused.
   Is there any way to set global mapping for every debug session? I’m able to set mapping during gdb session, however it’s not convenient. More, I have to use some environment variables like $(username) and $(ProjectDir) to construct actual mapping, which isn’t seems to be possible in “Source file path mapping” of GDB session.
   Duplication of sources in visualgdb cache is a bad idea because of code base source.

Some other problems that I have encountered:

1. Am I right that the only way to make IntelliSense work properly on custom solutions is enabling Clang IntelliSense and adding all include directories manually? (according to https://visualgdb.com/tutorials/arm/import/ )
2. When a project is inside a virtual folder of a solution (created in Solution explorer but not on a file system), opening a .vgdbsettings file leads to an error “No project in the current solution corresponds to .vgdbsettings. Cannot edit settings visually.” Even though I’m able to edit options from context menu opened with Shift, I’d appreciate to edit them directly.

For clearance I attach a template .vgdbsettings file of main executable project.

Looking forward for your suggestions.

Anton K

• This topic was modified 6 years, 6 months ago by Zoellick.
• This topic was modified 6 years, 6 months ago by Zoellick.
• This topic was modified 6 years, 6 months ago by Zoellick.
• This topic was modified 6 years, 6 months ago by Zoellick.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Please try updating to VisualGDB 5.4 Preview 7 if you are not using it yet. It will ask whether you want to inherit the project settings from the startup project when you attach to your executable.

Another option would be to select “Attach” in VisualGDB Project Properties -> Debug Settings and use the regular F5 shortcut to start debugging.

Both options will honor the extra gdb commands added via VisualGDB Project Properties and custom path mappings.

You can use the regular VC++ (non-Clang) IntelliSense on imported projects as well, although using Clang IntelliSense makes it easier (e.g. it can search for missing headers and automatically insert the missing directories into project properties).

The virtual folder bug looks like something that was fixed in v5.4. Please let us know if you can still reproduce the problem after updating to this version.

[Zoellick]

Hello!

Thank you!

Attach options – is definitely what I needed! Thanks!
Although “set debug-file-directory” added in additional GDB commands isn’t working. Possibly because of the target is set on gdb startup and debug-file-directory has no effect. Workaround is to replace this command with “file $(TargetDir)/executable.debug”. Symbols will be forced to load from given file.

What for “The virtual folder bug” is I’m using VisualGDB 5.4 Preview 7, so it doesn’t seem to be fixed.

As for IntelliSense, I’ll research it lately, as it’s less priority problem.

Another thing I noticed while setting debug environment is when I use Attach to process dialog, Visual GDB is looking for config named $(ProjectName)-$(Configuration).vgdbsettings, but not $(ProjectName)-$(Configuration)-$(Platform).vgdbsettings as set in NMake output. I see that the target platform may be different from one chosen in VS build settings, but is it reliable to assume VisualGDB will look for $(ProjectName)-$(Configuration).vgdbsettings while attaching to any remote process?

And one more question I forgot to ask.
I added VisualGDB support for all 30+ projects next way:
at first I created a template project with default settings, which was custom build project with NMake settings,
then I copied and renamed all .vgdsettings into project directories and renamed them respectively to project names
than thing gone wrong. When I added new configurations in VS Configuration Manager, it was added as MsBuild configuration, not NMake.
Workaround for me was editing each .vcxproj file manually, which doesn’t seem right to me.
Is there any way to get Nmake project, adding GDB Debug configuration to project, instead of MsBuild configured project?

Thanks to your support!

[Zoellick]

Pls, ignore “Another thing I noticed while setting debug environment is when I use Attach to process dialog” paragraph – it’s totally my fault.

[support]

Hi,

Thanks for confirming the bug with the solution folder. We have fixed it in this build (please note that it contains an incomplete experimental feature of Clang IntelliSense that might cause random crashes).

Regarding the VS configurations manager, please double-check that you are using the correct platform. We have a detailed tutorial showing various supported combinations here:  https://visualgdb.com/tutorials/porting/multiplatform/

Normally just editing multiple projects at once via VS project properties should work.

Also if this is remotely possible, please consider switching your projects to use CMake. The VisualGDB’s Advanced CMake Project Subsystem supports multiple targets per project and can automatically edit the CMake scripts for you, while providing familiar MSBuild-like property pages for common CMake properties. It also eliminates the need to maintain VC++ projects duplicating the underlying Linux projects, as it queries the precise project structure from CMake and renders it in Solution Explorer. It will also store common build/debug settings for all targets in one .vgdbcmake file, while letting you specify per-target settings (e.g. deployment options). Finally, it comes with a CMake script debugger, so if your projects involve custom build steps, you can easily troubleshoot them by literally stepping through the build scripts in debugger. You will also enjoy faster build times if you are using it with the Ninja build tool (it’s much more heavily optimized than GNU Make).

We do realize that switching the build system is a considerable effort, however based on the issues you have described so far, it may actually pay off as it will eliminate most of the problems you have mentioned.

You can find a quick overview of the Advanced CMake Subsystem workflow here: https://visualgdb.com/tutorials/linux/cmake/

[Zoellick]

Hello!

I’d checked the link before asked on test project, followed all steps precisely, but had no success. Still MS-like configuration created. Also tried Android approach without success. I hadn’t found any NMake reference in $(VISUALGDB_DIR) and have no idea where to dig. Changing build system isn’t possible, at least any time soon.

Thanks for advice on path mapping, works almost as desired. Although when I use project variables like $(ProjectDir) in paths, in setting editor GUI they are substituted correctly, but in GDB Session they don’t expand what leads to a manual editing of mapping for every user. Is there a workaround for the situation?

[support]

Hi,

Just to ensure we are on the same page, could you please summarize the current state of the problem with NMake paths? I.e. what you are trying to achieve and what you are observing.

We have also rechecked variable expansion in both path mappings and gdb commands and could not reproduce any errors. Please let us know the exact steps to reproduce the behavior you are observing and we will help you get it to work.

[Author]

Posts