Topic: Custom build steps after linking

This topic has 5 replies, 2 voices, and was last updated 5 years, 8 months ago by support.

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

Author

Posts
March 15, 2019 at 13:44 #24283
Jensa
Participant
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>
```
March 15, 2019 at 17:35 #24285

support
Keymaster

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.

March 18, 2019 at 11:27 #24316

Jensa
Participant

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

March 18, 2019 at 17:08 #24320

support
Keymaster

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?

March 19, 2019 at 09:08 #24340

Jensa
Participant

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

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

March 19, 2019 at 16:43 #24350

support
Keymaster

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

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

You must be logged in to reply to this topic.

Attachments: