Separate debug symbols file (.so) being stripped when running Nsight debugger

Developer Tools Nsight Visual Studio Edition
1

Hello,

Our Android project uses an external build system based on custom jam scripts and not the build scripts included within the Android NDK.

We strip the lib.so that is packaged within the APK and keep an external version of the lib.so that includes the debug symbols. The location of this lib.so is added to Additional Library Symbols Directories in the project properties.

Our issue:
Once our project solution is built we attempt to run the Nsight Tegra Debugger by pressing the play button. Even though Nsight is pointed to the location of the external lib.so containing debug symbols we only get disassembly and cannot breakpoint.

Observations:
We noticed when running the Nsight Tegra Debugger that our external lib.so file containing debug symbols gets stripped. We do not understand why. Using the tool Procmon we can see during the beginning stages of Nsight a call to arm-linux-androideabi-objcopy is made with the flag -S which strips the lib.so. We do not understand what is making this call or why.

I have made a HelloWorld project using the Android Project (External Build System) template closely mimicking our build process and Visual Studio settings. This project works as expected, Nsight will gladly break the c-native code and not strip the external lib.so.

I conducted the following test. Build both project solutions, then in the original projects additional symbols directory, three lib.so files were added:

  • the untouched original lib.so
  • a copy of the original lib.so with a completely different name
  • a copy of the lib.so built in the HelloWorld project

    • Both the untouched and renamed copy of the original lib.so get stripped but the HelloWorld built lib.so does not get edited in any way. Can someone please provide any additional information as to why this may happen?

    Thanks

    Mike

    2

    Update:
    When removing arm-linux-androideabi-objcopy from the Android NDK the Nvidia Nsight debugger throws error messages “…/arm-linux-androideabi-objcopy -S lib.so invocation failed”. Eventually Nsight continues and begins to breakpoint as expected.

    A temporary workaround is to point Nsight to a proxy Android NDK with arm-linux-androideabi-objcopy missing. This obviously is not ideal.

    If anyone can provide insight into this issue the help would be much appreciated.

    Thanks

    Mike

    3

    Solution:
    Our Nvidia Nsight debugger properties settings all worked fine on Windows 7. Transitioning to Windows 10 lead to this issue. The following solved the problem:

  • delete the contents of the property field Additional Library Symbols Directories
  • manually create a gdb.setup file pointing to the external lib.so
  • add gdb.setup file to the property field gdb.setup File Folder

    • See below an example gdb.setup file (only the single line needed):

    set solib-search-path path_to_file\lib.so

    Thanks

    Mike

    4

    Hey mike.hadley, this is a known problem that was resolved in the latest update of NT VSE 3.5 that you can download from the tool’s web page.

    As a workaround for the affected NT VSE version one should swap the binaries for objcopy and strip utilities: so the actual stip binary should be named objcopy and objcopy binary should be named strip.

    Let us know if it helps!

    5

    Hi,

    The version of NT VSE that we are using is 3.5.18024.1421. Ok great that has helped a lot :)

    Thanks

    Mike

    6

    Hi,

    Tested the proposed binary name swap workaround but still resulted in the external lib.so being stripped. I renamed aarch64-linux-android-objcopy.exe to aarch64-linux-android-strip.exe and vise versa. The HelloWorld project still worked fine even with the name changes.

    Thanks

    Mike

    7

    The feature is that a .gdb_index ELF section is generated for and appended to a .so file that is greater than a couple dozens MB in size.
    The .so produced by Hello World project is really tiny.

    The bug is that the paths to strip.exe and objcopy.exe are swapped in code, so instead of appending the ELF section all the debug information is stipped out of the ELF file.

    Thanks for the feedback mike.hadley, and note that the fixed version of the tool is already published.

    8

    Hi,

    Yes the HelloWorld version is tiny. Ok great and thanks again.

    Regards

    Mike

    9

    Try updating CodeWorks - the bug is resolved in NT VSE 3.5.18065.5230, that can be downloaded and installed using the CodeWorks component manager or manually from [url]https://developer.nvidia.com/gameworksdownload[/url]

    10

    Hi,

    OK good to know its been updated in a more recent version. We did not get our NT VSE from CodeWorks but via https://developer.nvidia.com/gameworksdownload.

    Thanks

    Mike