- This topic has 5 replies, 2 voices, and was last updated 2 years, 6 months ago by
.
-
Posts
-
Hi,
We’re having some issues with getting the option “Strip debug symbols during deployment” to work.
Before that option was implemented we were doing that step ourselves for our largest projects, especially for our bigger unit tests. For that we used the “Custom debug steps” to do it and it worked fine.
However, I’ve been doing a lot of Windows development lately and gotten used to the convinence of the “Test Explorer” for the unit tests. And the “Custom debug steps” option to strip the symbols doesn’t work for that for obvious reasons.So now when I was starting to do more serious development again using VisualGDB I saw the nice option to strip them automatically. However I can’t seem to get it to work, the deployed file is identical regardless of the status of that option from what I can see. I can also not see any logging output of it actually trying to do anything.
Did I missunderstand that option or is something going wrong?
Regards
Jens NilssonHi,
The “Strip debug symbols during deployment” option simply runs the toolchain’s objcopy executable on the primary output of each project before deploying it:
...-objcopy.exe --strip-debug <ELF file> <ELF file>-stripped
The <ELF file>-stripped file is then deployed to the target and deleted locally.
You can double-check what is going on by checking View->Other Windows->VisualGDB Diagnostics Console. You can also try running your toolchain’s objcopy executable (on the build machine) on the deployed ELF file to see if it manages to strip the symbols.
When I enabled that logging I don’t really get that much there.
This is the only output I get when I do a “Project Only” -> “Rebuild” of one of our test projects.
Locating deployed dependencies for project…
Locating deployed dependencies for project…
Locating deployed dependencies for project…
Locating deployed dependencies for project…
Locating deployed dependencies for project…
Locating deployed dependencies for project…
Locating deployed dependencies for project…
Locating deployed dependencies for project…
Locating deployed dependencies for project…
Locating deployed dependencies for project…
Locating deployed dependencies for project…
Locating deployed dependencies for project…
Warning: test discovery took 1328 msecIn our case when we do it manually we’re using the ‘strip.exe’ instead of the objcopy to do it. I’ll see if the objcopy one works tomorrow.
I got a bit better output when I tried to debug one of the projects, then I got some relevant output:
Locating deployed dependencies for project…
Locating deployed dependencies for project…
ShouldRedirectToVisualGDBImpl(): Y:\OsPortabilityPlatform\OsLed\_test\OsLedGUnitTest\_build\target\CT150\UsingProjectSource\visualGDB-msvc-2017\OsLedGUnitTest-Ct150p-Arm-Linaro-6.2.1-Debug.vgdbsettings vgdb://TargetPath=Y:\OsPortabilityPlatform\OsLed\_test\OsLedGUnitTest\_build\target\CT150\UsingProjectSource\visualGDB-msvc-2017\..\..\..\..\..\_bin\target\Ct150p\Ct150p-Arm-Linaro-6.2.1-Debug\OsLedGUnitTest
Locating deployed dependencies for project…
failed to strip debug symbols from Y:\OsPortabilityPlatform\OsLed\_test\OsLedGUnitTest\_build\target\CT150\UsingProjectSource\visualGDB-msvc-2017\..\..\..\..\..\_bin\target\Ct150p\Ct150p-Arm-Linaro-6.2.1-Debug\OsLedGUnitTest: —————— qg3+w ——————qg3+w: Failed to start process ($(ToolchainDir)\bin\arm-linux-gnueabi-objcopy.exe –strip-debug “Y:\OsPortabilityPlatform\OsLed\_test\OsLedGUnitTest\_build\target\CT150\UsingProjectSource\visualGDB-msvc-2017\..\..\..\..\..\_bin\target\Ct150p\Ct150p-Arm-Linaro-6.2.1-Debug\OsLedGUnitTest” “Y:\OsPortabilityPlatform\OsLed\_test\OsLedGUnitTest\_build\target\CT150\UsingProjectSource\visualGDB-msvc-2017\..\..\..\..\..\_bin\target\Ct150p\Ct150p-Arm-Linaro-6.2.1-Debug\OsLedGUnitTest-stripped”) in ” : The system cannot find the file specified —> System.ComponentModel.Win32Exception: The system cannot find the file specified
at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
at qg3.f()
— End of inner exception stack trace —
at qg3.f()
at ng3.d2(z7 f, String b, String c, String a, ExpandedEnvironment d, CommandFlags e)
at p12.g1(String b, String g, String d, ModifiedEnvirionment f, td2 e, Int32 a, CommandFlags c)
at j91.j(DependentArtifact a, Boolean b)
trace=[qg3.f:71, ng3.d2:22, p12.g1:15, j91.j:564]
—————— Inner exception ——————
—————— System.ComponentModel.Win32Exception ——————
System.ComponentModel.Win32Exception (0x80004005): The system cannot find the file specified
at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
at qg3.f()
trace=[System.Diagnostics.Process.StartWithCreateProcess:1008, qg3.f:12]
Is it missing to evaluate the real path to the objcopy exe? “Failed to start process ($(ToolchainDir)\bin\arm-linux-gnueabi-objcopy.exe”
All other paths there seems to have been evaluated correctly and running the command manually from the project folder works perfectly and I get a stripped file in the output folder:
“X:\CT150\gcc-linaro-6.2.1-2016.11-i686-mingw32_arm-linux-gnueabi\bin\arm-linux-gnueabi-objcopy.exe –strip-debug “Y:\OsPortabilityPlatform\OsLed\_test\OsLedGUnitTest\_build\target\CT150\UsingProjectSource\visualGDB-msvc-2017\..\..\..\..\..\_bin\target\Ct150p\Ct150p-Arm-Linaro-6.2.1-Debug\OsLedGUnitTest” “Y:\OsPortabilityPlatform\OsLed\_test\OsLedGUnitTest\_build\target\CT150\UsingProjectSource\visualGDB-msvc-2017\..\..\..\..\..\_bin\target\Ct150p\Ct150p-Arm-Linaro-6.2.1-Debug\OsLedGUnitTest-stripped”Hi,
Thanks for checking the debug output. Indeed, the stripping logic was not working with the custom imported toolchains, that internally use the $(ToolchainDir) syntax. We have fixed it in the following build: VisualGDB-5.6.105.4579.msi
- You must be logged in to reply to this topic.