Strip debug symbols during deployment

Sysprogs forums Forums VisualGDB Strip debug symbols during deployment

This topic contains 5 replies, has 2 voices, and was last updated by  Jensa 2 weeks, 1 day ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #32618

    Jensa
    Participant

    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 Nilsson

    #32619

    support
    Keymaster

    Hi,

    The “Strip debug symbols during deployment” option simply runs the toolchain’s objcopy executable on the primary output of each project before deploying it:

    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.

    #32620

    Jensa
    Participant

    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 msec

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

    Attachments:
    You must be logged in to view attached files.
    #32622

    Jensa
    Participant

    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”

    #32627

    support
    Keymaster

    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

    #32629

    Jensa
    Participant

    Hi,

    With that build it works perfectly!

    Thanks!

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.