2
votes

I've written a kernel for armv7-m (Cortex-Mx) microcontrollers. The kernel is capable of dynamically loading ELF files. When debugging in GDB all kernel symbols are loaded and I can single step through C++ source without issue. On dynamic loading application symbols get added using:

add-symbol-file app <base .text address> -s .data <base .data address> -s .bss <base .bss address>

I can then set breakpoints, step into main using the assembly view and print out the value of symbols such as argc/argv. Everything looks correct.

Except in source view it just shows [ No Source Available ]. I verified the application get compiled with -O0 -ggdb. Paths in the ELF app are correct. Messed around with GDBs set directories without luck.

What is the mechanism for resolving source in GDB? If symbols are loaded, the full ELF is available with debug info and sources remain in the same location as compilation what else could be wrong?

gdb-multiarch GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git

arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2018-q3-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]

Thanks!

1

1 Answers

0
votes

I was able to fix this my moving certain section above .text in the linker script. No idea why this changed anything... I figured it must alter alignment of section below but none of my experiments panned out.

  /* These MUST be before .text segment for proper symbolic debugging... */
  .dynstr         : { *(.dynstr) } > FLASH
  .hash           : { *(.hash) } > FLASH
  .dynsym         : { *(.dynsym) } > FLASH

Any explanation of why this may be would be much appreciated. Maybe due to some GDB internal assumptions?