Forum Replies Created
-
Posts
-
I understand fully, and as I say, I love the product. I was just surprised to find myself locked out! 🙂
The most obvious bit is…
The component assembly doesn’t exist:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\SysprogsVisualGDB\Sysprogs\BuildUpToDateCheck2015.dll…and indeed that file does not exist.
Same issue, I’m afraid. It’s not a VisualGDB project so I can’t capture a log that way. (It’s build using an in-house tool that redirects VC to use GCC.) But I’ve attached the GDB interactions captured from the debug window, and also a capture of the Local Variables window showing the issue.
Here are the extracts from the startup log that mention GDB…
<entry> <record>127</record> <time>2019/10/27 16:22:34.449</time> <type>Information</type> <source>Extension Manager</source> <description>Successfully loaded extension...</description> <path>C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\Sysprogs\VisualGDB\</path> </entry> <entry> <record>128</record> <time>2019/10/27 16:22:34.450</time> <type>Information</type> <source>Extension Manager</source> <description>Extension is enabled...</description> <path>C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\Sysprogs\VisualGDB\</path> </entry> ... <entry> <record>189</record> <time>2019/10/27 16:22:34.503</time> <type>Information</type> <source>Microsoft.VisualStudio.CommonIDE.ExtensibilityHosting.VsShellComponentModelHost</source> <description>Successfully loaded component assembly from cache</description> <path>C:\Program Files (x86)\Sysprogs\VisualGDB\VisualGDBPackage2010.dll</path> </entry> ... <entry> <record>275</record> <time>2019/10/27 16:22:38.805</time> <type>Warning</type> <source>Microsoft.VisualStudio.CommonIDE.ExtensibilityHosting.VsShellComponentModelHost</source> <description>The component assembly doesn't exist:</description> <path>C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\Sysprogs\VisualGDB\SysprogsBuildUpToDateCheck2015.dll</path> </entry> ... <entry> <record>309</record> <time>2019/10/27 16:22:39.145</time> <type>Information</type> <source>VSCommands</source> <description>Installed Extensions Process Template Editor State = Enabled Version = 2.0 WITDesigner State = Enabled Version = 2.0.0.0 VisualGDB State = Enabled Version = 5.4 Productivity Power Tools State = Enabled Version = 10.0.20626.18 Align Assignments State = Enabled Version = 1.3 VSCommands for Visual Studio 2010 State = Enabled Version = 10.3.9.12 Wix Toolset Visual Studio 2010 Extension State = Enabled Version = 1.0.0.4 </description> </entry>
Had already installed and remove an arbitrary extension to refresh the cache, but tried again (Hide Main Menu, FWIW) and still no joy. The VisualGDB commands do not appear in the Customize dialog.
Okay. I found it. It’s disabled when I’ve got the project in the Win32 configuration, but it comes back if I flip to one of my custom Linux configurations. (I’m not using VisualGDB’s configuration type, but instead some custom MSBuild magic.) Sorry for the false alarm! I’ll get my coat… 🙂
Just to clarify: The project is a Visual Studio Cross-Platform Linux project set to build on a remote Linux machine. I’m then running it on a different machine, an embedded Linux device. So the source code won’t exist on the debug target. It’ll just be on the Windows host machine and on the Linux build machine, the latter of which won’t be visible to the debug target. Do you still want me to proceed?
Turning off the ‘Hide Missing Source Files’ option does indeed fix the problem, so it looks like it’s thinking that a file is missing when in fact it is available. If I install the build you provided and have this option checked, the same failure occurs. The resulting diagnostic log is attached. It looks like it’s seeing the Linux-style path from the build machine, and not converting it to the Windows equivalent. Disabling the option still fixes the problem.
I tried the new release, and…
- The SSH issue is now resolved.
- The Intellisense issue from 5.3r8 is still resolved.
- The original failure to debug is still resolved.
- The source code still does not display correctly.
I tried the stack trace approach, and that did not work. Double-clicking on the “main” entry did nothing. Selecting Show Source produced the Frame Not In Module window. Selecting Show Disassembly worked, and shows the assembly with the correct interspersed source lines. Attached is the GDB log from the failing case with the latest release, and the working case with 5.3r8. A quick diff shows very little difference between the files, except a change in the order of a few commands.
Yep, with the build you posted, when I do debug, I get the unknown source file page every time. Under 5.3, it would correctly go to my application’s main, and then show the various breakpoints I’d set. With the posted build, the breakpoints would be hit and I could show the mixer assembly, but the pure source was never displays.
That seems to fix the debug issue, but the SSH Connection Manager now won’t let me open a console. (See attached.)
Also, I don’t seem to be getting proper source code display, but let me confirm that…
Since it wouldn’t let me upload the preset…
<?xml version=”1.0″?>
<QuickDebugPreset xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
<InitialBreakpoint>main</InitialBreakpoint>
<InteractiveStartup>false</InteractiveStartup>
<Name>mCore</Name>
<Timestamp>2019-01-06T12:22:34.9732384-05:00</Timestamp>
<Settings xsi:type=”com.visualgdb.quickdebug.program”>
<RemoteHost>
<HostName>mcore-local</HostName>
<Transport>SSH</Transport>
<UserName>root</UserName>
</RemoteHost>
<ToolchainID>
<ID>linaro-gcc-7.3.1</ID>
<Version>
<GCC>7.3.1</GCC>
<GDB>(Linaro_GDB-2018.05)</GDB>
<Revision>0</Revision>
</Version>
</ToolchainID>
<DebuggedProgram>
<SkipWhenRunningCommandList>false</SkipWhenRunningCommandList>
<Command>/tmp/bin/LED_Server</Command>
<Arguments />
<WorkingDirectory />
<Environment>
<Records />
</Environment>
<BackgroundMode xsi:nil=”true” />
</DebuggedProgram>
<GenerateCtrlBreakInsteadOfCtrlC>false</GenerateCtrlBreakInsteadOfCtrlC>
<RunGDBUnderSudo>false</RunGDBUnderSudo>
<CrossSettings>
<LocalProgramCopy>J:\Monico\GcLab\Unify\bin\ARM\Debug\bin\LED_Server</LocalProgramCopy>
</CrossSettings>
</Settings>
<IsShared>false</IsShared>
</QuickDebugPreset>
