Custom build steps after linking

[Jensa]

Hi,

I’m trying to save some time by making the output smaller by stripping out the debug symbols etc on the output that’s copied and run on the target. Currently I’m trying to do this as a custom build stpe done after building but I’m running into some issues. The problem is that if I run it twice without doing any changes it will not link the second time but still run my custom “After building” script that will move the no longer existing debug symbols to the .debug file resulting in an empty file.

Ideally I would like a “After linking” build step that is only run if the linker is actually run. Or potentially adding that option to the after building step. I’m not really sure how it works under the hood when it decides not to link etc (or if it’s the linker that still runs but decides not to do anything despite the output file is changed since the last time). Basically I just need a way to know if the linker ran (and did something) to know if I should run my scripts or not.

Here are the custom steps I’m running to strip it:

<?xml version="1.0" encoding="utf-16"?>
<ArrayOfCustomActionBase xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <CustomActionBase xsi:type="CommandLineAction">
    <SkipWhenRunningCommandList>false</SkipWhenRunningCommandList>
    <RemoteHost>
      <HostName>BuildMachine</HostName>
      <Transport>BuiltinShortcut</Transport>
    </RemoteHost>
    <Command>$(ToolchainDir)\arm-linux-gnueabi\bin\objcopy.exe</Command>
    <Arguments>--only-keep-debug $(TargetPath) $(TargetDir)\$(TargetFileName).debug</Arguments>
    <WorkingDirectory>$(BuildDir)</WorkingDirectory>
    <BackgroundMode>false</BackgroundMode>
  </CustomActionBase>
</ArrayOfCustomActionBase>

<?xml version="1.0" encoding="utf-16"?>
<ArrayOfCustomActionBase xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <CustomActionBase xsi:type="CommandLineAction">
    <SkipWhenRunningCommandList>false</SkipWhenRunningCommandList>
    <RemoteHost>
      <HostName>BuildMachine</HostName>
      <Transport>BuiltinShortcut</Transport>
    </RemoteHost>
    <Command>$(ToolchainDir)\arm-linux-gnueabi\bin\strip.exe</Command>
    <Arguments>--strip-debug --strip-unneeded $(TargetPath)</Arguments>
    <WorkingDirectory>$(BuildDir)</WorkingDirectory>
    <BackgroundMode>false</BackgroundMode>
  </CustomActionBase>
</ArrayOfCustomActionBase>

<?xml version="1.0" encoding="utf-16"?>
<ArrayOfCustomActionBase xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <CustomActionBase xsi:type="CommandLineAction">
    <SkipWhenRunningCommandList>false</SkipWhenRunningCommandList>
    <RemoteHost>
      <HostName>BuildMachine</HostName>
      <Transport>BuiltinShortcut</Transport>
    </RemoteHost>
    <Command>$(ToolchainDir)\arm-linux-gnueabi\bin\objcopy.exe</Command>
    <Arguments>--add-gnu-debuglink=$(TargetDir)\$(TargetFileName).debug $(TargetPath)</Arguments>
    <WorkingDirectory>$(BuildDir)</WorkingDirectory>
    <BackgroundMode>false</BackgroundMode>
  </CustomActionBase>
</ArrayOfCustomActionBase>

[support]

Hi,

As VisualGDB supports many different build systems, its custom action logic treats build as a single “black box” step, hence they will indeed run after the build regardless of the actual steps performed during the build. If you would like a finer-grain control over this, we would advise creating custom targets with the build system you are using (e.g. see this tutorial for custom MSBuild targets) or try searching CMake documentation if you are using CMake (stripping symbols is a fairly common task, so there might be ready-to-use snippets posted on StackOverflow or other forums).

If you don’t want to modify the build system settings, please consider changing your file structure so that the custom actions won’t overwrite any files. E.g. copy $(TargetPath) to $(TargetPath).target, then move debug symbols to $(TargetPath).debug and finally strip $(TargetPath).target. You would need to update the debug and deployment settings to deploy/launch $(TargetPath).target instead of $(TargetPath), but as long as you do that, the building and debugging will work as expected and the symbols won’t get lost.

[Jensa]

Thanks for the tip,

The second option seemed simplest but I ran into an issue. The “Source path” in the deployment settings isn’t editable so I can’t change the application that’s deployed. It looks like it’s supposed to be editable though since it’s not greyed out but no caret shows up when trying to edit it and nothing gets changed when typing?

Regards
Jens Nilsson

[support]

Strange. Just to be 100% sure, could you please attach a screenshot and show the exact setting that is not editable, so that we could recheck everything on our side?

[Jensa]

The source path in the “Debug settings” tab under “Deployment”. See screenshot.

Attachments:

You must be logged in to view attached files.

[support]

Thanks for the screenshot. This path is indeed automatically derived from the build-level settings and cannot be changed. We will consider showing it in a different color in one of the next VisualGDB releases to avoid further confusion.

As a workaround, please disable deployment on the Debug Settings page and try adding a custom action for uploading the stripped file via pre-debug actions.

[Author]

Posts