Using -d option for compiling causes error

I am trying to use GDB for debugging and as the documentation suggests used -d to generate symbols; I am getting the following error:
[5/9] Linking C library
_FAILED: /opt/swi/y17-ext/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc --sysroot=/opt/swi/y17-ext/sysroots/armv7a-vfp-neon-poky-linux-gnueabi -Wl,–build-id -g -shared -o _build_gpioCf3Demo/wp85/staging/read-only/lib/ _build_gpioCf3Demo/wp85/component/4087e26d369e060c006ea8351045bd53/obj/e27b33ef46e2835b19e10829a05c1dcb.o _build_gpioCf3Demo/wp85/api/de8215af72a76ce25f0abab7714a1199/client/le_gpioPin25_client.c.o _build_gpioCf3Demo/wp85/component/4087e26d369e060c006ea8351045bd53/obj/_componentMain.c.o -L_build_gpioCf3Demo/wp85/staging/read-only/lib -Wl,–enable-new-dtags,-rpath="$ORIGIN/…/lib" “-L$LEGATO_BUILD/framework/lib” -llegato -lpthread -lrt -lm && splitdebug -d dpio_Debug/ build_gpioCf3Demo/wp85/staging/read-only/lib/
_objcopy: Unable to recognise the format of the input file `build_gpioCf3Demo/wp85/staging/read-only/lib/’
ninja: build stopped: subcommand failed.

Can any one help with this issue ??

How are you setting your toolchain? The -d option use the objcopy tool, and it looks like the objcopy that mkTools is trying to use doesn’t match the compiler it’s using. This could occur (for example) if you set either the CC or <target>_CC environment variables without setting the corresponding OBJCOPY variable.

@kdunwoody I have installed the arm-poky toolchain as per instructions; it resides in /opt/swi/ folder; before compiling I source the toolchain and the legato environment.

_This could occur (for example) if you set either the CC or CC environment variables without setting the corresponding OBJCOPY variable.

As of now I am not setting anything; the ninja script is generating the build.config automatically, and in the build.config, OBJCOPY is assigned to the one which accompanies the arm-poky toolchain. I also tried replacing the original objcopy with a softlink to the arm-poky one with no avail.

@kdunwoody How can I manually set the CC, _CC and OBJCOPY ??

If you’re not setting these variables manually now, I wouldn’t mess with them. In your case (where you’re using a pre-built toolchain installed in /opt/swi), you shouldn’t need to touch these. But if they are defined, mkTools will take compiler, linker, etc. paths from environment variables. How to set environment variables depends on which shell you’re using – check the documentation for your shell.

Are you either running bin/legs or sourcing bin/configlegatoenv first? If so, can you send me:

  • the output of the env command
  • the full output of whatever mk command you are running.

Preferably in a file attached to your post; the forum software will remove important characters (like _) if you’re not careful.

@kdunwoody Yes I am using a pre-built toolchain; I do source the toolchain environment and the legato environment before using target specific mkapp or make commands. Please find the documents you asked for, attached.
mkapp without -d option:
mk_LOGS.txt (10.7 KB)

mkapp with -d option:
mk_-d_LOGS.txt (11.1 KB)

sourcing legato environment:

@kdunwoody Just noticed that using make wp85 in Legato doesnot generate debug symbols in build/wp85/debug as the documentation claims. Is this to be expected or could this be related to the issue ?

Can you also send me the output of the env command?

Are you checking for hidden directories? Debug output is generated into a hidden directory (i.e. actual debug symbols will be in build/wp85/debug/.build-id).

@kdunwoody Find the output to the env command attached.

env_command.txt (7.2 KB)

You have
WP85_TOOLCHAIN_DIR=/opt/swi/y17-ext/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi, but your path starts with PATH=/opt/swi/y17-ext_1706/sysroots/x86_64-pokysdk-linux/usr/bin. So I guess stripdebug may be using objcopy from /opt/swi/y17-ext_1706, but gcc from /opt/swi/y17. Can you try unsetting the OBJCOPY&STRIP environment variables, and remove /opt/swi/y17-ext_1706 from your path?


y17-ext is a softlink for y17-ext_1706[this folder contains the toolchain].

I tried rewriting PATH with only y17-ext and then WP85_TOOLCHAIN_DIR with y17-ext_1706; both had no luck.

@kdunwoody It seemed the issue was with the fact that the mkapp was still somehow using /usr/bin/objcopy and /usr/bin/strip; I manually softlinked them to the necessary files and the original error no longer appears;

But now the issue is with the GDB : Please find the logs attached.

gdb_log.txt (1.4 KB)

Even though the log says no debug symbols were found I found them in /Workspace/gpioCf3Demo/dpio_Debug [The folder I had given as -d option] as hidden folder as you said earlier.

How to use these debug symbols is described in

@kdunwoody I am following those steps; I am attaching my gbd logs; please go through and help me find the issue with the debug symbols loading:

gdb_log_2.txt (1.7 KB)

IIRC you have to do set debug-file-directory /home/febin/Workspace_Gen35/gpioCf3Demo/dpio_Debug (i.e. no .build-id on the end). Check the gdb docs to be sure though (or just try it).

Hi @kdunwoody I had to use add-symbol-file to manually add .debug files to PROGBIT address locations found after using readelf on the binary file generated in the _build_gpioCf3Demo/wp85/app/gpioCf3Demo/staging/read-only/bin/gpioCf3Demo path.

After this I was able to debug sample apps using GDB and DDD.