We will have an integrated gdb option in a few months. It's not very stable at the moment so maybe atmel studio is the best solution

Atmel studio can be clunky and the following might not be of use.... You install visual micro into atmel studio then enable use "vmicro>debugger>use atmel studio debugging". You can also follow the guide to use a projectname.cpp instead of .ino files. This combination might avoid the need to use "open object file". The Visual Micro build should put the object file in the place that atmel expects it. If you use visual micro to build in atmel studio then it is recommended to have "show hidden files" enabled so that atmel can find the sources more easily.

You can override any build pattern that is designed into the core you are using. If you switch on "vmicro>compiler>show build properties" you will see the pattern that is specified when cpp, c or s files are built. Copy the entire pattern line into a local project board.txt and you will have overriden the compiler settings. Where the -g setting is used will be shown in the properties.

The visual micro project properties such as flags are used for build. The "(global)" properties are applied always, the (configurations) properties are for the current configuration such as Release or Debug.

Showing local variables might improve with different optimization settings. You can also push prama settings in the code to affect optimization for certain code without having to switch off optimization for all.

Makes sense.

There is a vMicro>add code menu item and tool bar item that creates the board.txt for you in the project folder and includes it in the solution explorer. or can do manually.

Last evening I saw that the VM GDB is preview, not prerelease. We would like to work with VM to see if we can get the Segger J-Link to function with VM, seems like a reasonable stretch as the Atmel SAM-ICE is in fact an OEM version of the Segger J-Link Base.  With the demise of the Arduino Zero, we had to switch to outboard debuggers and move from boards with embedded Atmel-EDBG chipsets. However, authoring with VM-Visual Studio and debugging under VM-Atmel Studio is painful at best.

Didn't get very far before 1st speedbump attempting VM-GDB...   

I am unable to see the get the "Microsoft GDB Debugger" to appear at the top of the vMicro > Debugger menu.  I have uninstalled and reinstalled "Arduino GDB for Visual Micro 2017" (v 15.170821.1).

Checking the registry path Computer\HKEY_CURRENT_USER\Software\Visual Micro\Options\Debug General path, I am able to verify the MicroGdb Location is populated and the directory exists on the filesystem. However there is no microdbg.exe file in that directory (I can find other expected items such as OpenOCD).

Following some other posts, I next uninstalled and reinstalled Visual Micro for VS2017 since there was a comment that VM install copied the microdbg.exe file. Nope, still no microdbg.exe file in the registry referenced location.

Should I try to manual place the microdbg.exe file? 
Or... is this a symptom of an upstream problem?
If so, were should I find the file?

Visual Micro ver: 1807.8.0
Visual Studio ver: 15.7.5

Thanks,
Greg

yes, it had been previously installed for a different project.  But to be sure I also uninstalled the "Mobile developement with C++" workload and reinstalled it, within Visual Studio Installer.

I opened up the .vsix (aka renamed to .zip), I noticed that you are targeting community, we are running VS Professional.   

<Installation>
    <InstallationTarget Id="Microsoft.VisualStudio.Community" Version="[15.0]" />
</Installation>

Ignore the microsoft vsix chaos, you can see what you have installed in tools>extensions and updates also in help>about. You are get an install message when installed and a no ide's to install in when it fails.

The "vMicro>Help>Install Gdb" page contains a link to 3rd party gdb config settings info