MCUXpresso IDE project missing symbols (no -s)

[benedek_kupper]

I have an NXP i.MX RT1010 project, which is a modification of an example project. There's a lot of precompiled libraries from a third party, which may be relevant. This configuration (Debug) builds just fine, however the resulting .axf executable doesn't contain any symbols, even though Omit all symbol information (-s) is not enabled. I see this through the Executables view in the IDE, and also during debugging there are no symbols matched to the running program, so I can only debug the disassembled instructions. I have attached the .cproject configuration that I'm using.

[benedek_kupper]

Let me shed some more light on what's happening:

The only breakpoint I can set is via the Debug Configuration/Startup/Set breakpoint at:, the debugger is able to halt the core at this breakpoint, but cannot show the corresponding source code. Instead, it pops up the "No source available at ..." message. Breakpoints added in any other way aren't stopping execution, even if they have been obviously crossed (e.g. ResetISR()).

So what I'm suspecting is that the .axf format ends up being somehow special in a way that the MCUXpresso tools can parse it, but the generic Eclipse/gdb/arm tools cannot.

(The optimization level doesn't matter, the behavior is the same in all levels. And (obviously) I'm not trying to debug precompiled libraries.)

[converse]

One other possibility is there is a mismatch between the files/filenames/paths between when they are built to when they are executed. Are you using linked files, or symbol links, or Eclipse linked directories in your project? Does the path to the file (on disk) contain any 'special' characters (anything that is not alphanumeric, '-', '_')?

Did you say that the program itself is working? Or is it possible that it could have vectored into the weeds? Have you tried just pausing execution, and looking to see where the PC is located? Is it somewhere within your application, or is it elsewhere?

Is there any chance you can post your axf file?

[benedek_kupper]

I have attached the current .axf. There is a linked resource folder in the project, but it's not on any special path, and if I copy the folder to the project instead, the result is the same. My application is running, because on the UART console I'm getting the messages, and the one possible breakpoint also halts at my called function.

[converse · Accepted solution]

After a bit of experimentation (with my own project) it looks like the problem is caused by the *compiler* -flto option. Although not stated in the documentation, this option appears to remove some of the debug information from the final image. Try removing this flag (from all compiles) and rebuild and debug, and see if that helps.

[benedek_kupper]

You are right, at first I found the -flto flag in the MCU Linker settings, but it didn't fix it. Now I've found that the same setting exists for the MCU Compiler. If I uncheck it, the symbols appear in the Executables view. Thank you!

[ErichStyger]

Instead looking at the .cproject, could you have a look at the command line passed to the compiler and linker in the Console View? That would give you the options passed to the tools.

[benedek_kupper]

These are my commands during build, none of them reveal to me anything wrong (I have replaced paths with indications for readability):

Invoking: MCU C Compiler
arm-none-eabi-gcc -std=gnu99 -D__REDLIB__ -DCPU_MIMXRT1011DAE5A -DCPU_MIMXRT1011DAE5A_cm7 -DSDK_DEBUGCONSOLE=1 -DXIP_EXTERNAL_FLASH=1 -DXIP_BOOT_HEADER_ENABLE=1 -DCR_INTEGER_PRINTF -DPRINTF_FLOAT_ENABLE=0 -D__MCUXPRESSO -D__USE_CMSIS -DDEBUG -DDEBUG_CONSOLE_TRANSFER_NON_BLOCKING=1 -DDEBUG_CONSOLE_TRANSMIT_BUFFER_LEN=3000 -DDEBUG_CONSOLE_RECEIVE_BUFFER_LEN=64 -DSDK_DEBUGCONSOLE_UART=1 -I"[include paths]" -O3 -fno-common -g3 -Wall -c  -ffunction-sections  -fdata-sections  -ffreestanding  -fno-builtin -flto -ffat-lto-objects -fmacro-prefix-map="../source/"=. -mcpu=cortex-m7 -mfpu=fpv5-sp-d16 -mfloat-abi=hard -mthumb -D__REDLIB__ -fstack-usage -specs=redlib.specs -MMD -MP -MF"source/HCITRANS.d" -MT"source/HCITRANS.o" -MT"source/HCITRANS.d" -o "source/HCITRANS.o" "../source/HCITRANS.c"

Invoking: MCU Linker
arm-none-eabi-gcc -nostdlib -L"[library paths]" -Xlinker -Map="evkmimxrt1010-cc256x.map" -Xlinker --gc-sections -Xlinker -print-memory-usage -Xlinker --sort-section=alignment -Xlinker --cref -flto -O3 -mcpu=cortex-m7 -mfpu=fpv5-sp-d16 -mfloat-abi=hard -mthumb -T "evkmimxrt1010-cc256x_Debug.ld" -o "evkmimxrt1010-cc256x.axf" [object files] -l[libraries]

[converse]

Are you building for Debug or Release?

I'm not sure why you are not getting debugging symbols, but

- you are compiling with maximum optimisation (-O3), so whatever you get is going to be very difficult to debug

- you are also linking with link-time optimisation, and again, it is cranked uptimes to the maximum, making debug even more difficult.

See https://community.nxp.com/thread/388981 

You can also check what is in the image by right-click on the .axf file, and select Binary utilities->Disassemble. This should show symbolic names for functions and show data in the Symbol Table. Also the Image Info tab should show symbolic information

[benedek_kupper]

I'm building Debug, and I'm using optimizations to minimize the RAM usage, which is a scarce resource in this case.

The file disassembly shows the function names with their address, and I can also see them in the Image Info view. So the question is, why can't I debug the image properly, or see any contents in the Executables view (the example projects work fine in both cases)?

[converse]

Have you set a breakpoint on main() (assuming that it is code to which you have source code) and seen what happens there? Perhaps you could take a screenshot to show us your problem?

Note that if you are using libraries, then you are unlikely to be able to do source-level debugging in those libraries, unless you have been provided source.

I also to re-iterate, even when you get source code, trying to debug with such a high level of optimisation is going to be a real struggle - there is often no one-one mapping between assembler and source code.

[Just thought - as an experiment, can you compile with a lower level of optimisation (-Og is meant to be a good compromise between debugability and code size). Also, remove the link time optimisation flags]

[And another thought - you are compiling -O3. This is for fastest code NOT for *smallest* code. If you want smallest code, use -Os (optimise for space) as O3 can *increase* the size of your code!]