# Arm-none-eabi-nm: some symbols are not related to any source file **URL:** \ **Category:** General\ **Created:** [February 17, 2020, 8:29pm UTC](https://community.memfault.com/t/arm-none-eabi-nm-some-symbols-are-not-related-to-any-source-file/145 "2020-02-17T20:29:25Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![mastupristi](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.memfault.com/mastupristi/32/32_2.png) [@mastupristi](https://community.memfault.com/u/mastupristi)\ **Post date:** [February 17, 2020, 8:29pm UTC](https://community.memfault.com/t/arm-none-eabi-nm-some-symbols-are-not-related-to-any-source-file/145/1 "2020-02-17T20:29:26Z")
In my embedded project I compile `amazon-freertos/lib/FreeRTOS-Plus-TCP/FreeRTOS_Sockets.c` in this way: ```nohighlight /opt/gcc-arm-none-eabi-8-2019-q3-update/bin/arm-none-eabi-gcc \ -std=gnu11 \ -mcpu=cortex-m7 \ -mthumb \ -mapcs \ -mfloat-abi=hard \ -mfpu=fpv5-d16 \ -fno-common \ -fno-math-errno \ -fsingle-precision-constant \ -fno-trapping-math \ -fno-signaling-nans \ -fno-builtin \ -fstrict-aliasing \ -fstack-usage \ -Wstack-usage=300 \ -DCPU_MIMXRT1051DVL6B \ -D __FREERTOS__ =1 \ -DFSL_RTOS_FREE_RTOS \ -DFSL_FEATURE_PHYKSZ8081_USE_RMII50M_MODE \ -D__MCUXPRESSO \ -D__USE_CMSIS \ -DARM_MATH_CM7 \ -D __NEWLIB__ \ -DDEBUG=0 \ -IDSP/source/ \ -Iamazon-freertos/lib/FreeRTOS-Plus-TCP/ \ -Iamazon-freertos/lib/FreeRTOS-Plus-TCP/portable/BufferManagement/ \ -Iamazon-freertos/lib/FreeRTOS-Plus-TCP/portable/NetworkInterface/imxrt105x/ \ -Iamazon-freertos/lib/FreeRTOS/ \ -Iamazon-freertos/lib/include/ \ -Iamazon-freertos/lib/FreeRTOS/portable/GCC/ARM_CM4F/ \ -Iamazon-freertos/lib/FreeRTOS/portable/MemMang/ \ -Og \ -g3 \ -Wall \ -ffunction-sections \ -fdata-sections \ -c \ -MMD \ -MP \ -Werror \ --specs=nano.specs \ -Wa,-anhlmsd=build/DSP/amazon-freertos/lib/FreeRTOS-Plus-TCP/FreeRTOS_Sockets.lst \ -o build/DSP/amazon-freertos/lib/FreeRTOS-Plus-TCP/FreeRTOS_Sockets.o amazon-freertos/lib/FreeRTOS-Plus-TCP/FreeRTOS_Sockets.c ``` I have `ipconfigUSE_TCP` set to 1 in `amazon-freertos/lib/FreeRTOS-Plus-TCP/include/FreeRTOSIPConfig.h` `FreeRTOS_Sockets.c` declares `xBoundUDPSocketsList` and `xBoundTCPSocketsList` ```auto /* The list that contains mappings between sockets and port numbers. Accesses to this list must be protected by critical sections of one kind or another. */ List_t xBoundUDPSocketsList; #if ipconfigUSE_TCP == 1 List_t xBoundTCPSocketsList; #endif /* ipconfigUSE_TCP == 1 */ ``` Once I have my elf executable linked, run this command: ```nohighlight $ /opt/gcc-arm-none-eabi-8-2019-q3-update/bin/arm-none-eabi-nm -a -l -n -t x --print-size image/DSP.elf | grep -E '^[[:xdigit:]]{8} [[:xdigit:]]{8} B' | grep SocketsList 2001ac7c 00000014 B xBoundTCPSocketsList 2001ac90 00000014 B xBoundUDPSocketsList /home/max/Lavori/4202/src/repos/toremove/FW/amazon-freertos/lib/FreeRTOS-Plus-TCP/FreeRTOS_Sockets.c:162 ``` Both symbols exist in the executable, but one (`xBoundTCPSocketsList`) does not seem to belong to any .c source. Both appear on the map file: ```nohighlight $ grep -n -A 1 -E 'xBoundTCPSocketsList|xBoundUDPSocketsList' image/DSP.map 61974: .bss.xBoundTCPSocketsList 61975- 0x000000002001ac7c 0x14 ./build/DSP/amazon-freertos/lib/FreeRTOS-Plus-TCP/FreeRTOS_Sockets.o 61976: 0x000000002001ac7c xBoundTCPSocketsList 61977: .bss.xBoundUDPSocketsList 61978- 0x000000002001ac90 0x14 ./build/DSP/amazon-freertos/lib/FreeRTOS-Plus-TCP/FreeRTOS_Sockets.o 61979: 0x000000002001ac90 xBoundUDPSocketsList ``` Even addr2line fails: ```nohighlight $ arm-none-eabi-addr2line -a -e image/DSP.elf 2001ac7c 2001ac90 0x2001ac7c ??:0 0x2001ac90 /home/max/Lavori/4202/src/repos/toremove/FW/amazon-freertos/lib/FreeRTOS-Plus-TCP/FreeRTOS_Sockets.c:162 ``` even the `FreeRTOS_Sockets.lst` doesn’t tell me anything more: ```nohighlight 7337 .global xBoundTCPSocketsList 7338 .global xBoundUDPSocketsList 7339 .section .bss.xBoundTCPSocketsList,"aw",%nobits 7340 .align 2 7341 .set .LANCHOR2,. + 0 7344 xBoundTCPSocketsList: 7345 0000 00000000 .space 20 7345 00000000 7345 00000000 7345 00000000 7345 00000000 7346 .section .bss.xBoundUDPSocketsList,"aw",%nobits 7347 .align 2 7348 .set .LANCHOR1,. + 0 7351 xBoundUDPSocketsList: 7352 0000 00000000 .space 20 7352 00000000 7352 00000000 7352 00000000 7352 00000000 ``` There are many other symbols present in the executable but which do not seem to be associated with any .c source file. Why this behavior? What changes between the two symbols `xBoundTCPSocketsList` and `xBoundUDPSocketsList`? Am I getting it wrong or omitting some debugging parameters when compiling? How do I get either nm or some other way to get the .c source where a symbol is declared? best regards Max ---
**Author:** ![francois](https://avatars.discourse-cdn.com/v4/letter/f/77aa72/32.png) [@francois](https://community.memfault.com/u/francois)\ **Post date:** [February 17, 2020, 10:06pm UTC](https://community.memfault.com/t/arm-none-eabi-nm-some-symbols-are-not-related-to-any-source-file/145/2 "2020-02-17T22:06:39Z")
Hi Max, Could you share the flags you used for linking as well? ---
**Author:** ![mastupristi](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.memfault.com/mastupristi/32/32_2.png) [@mastupristi](https://community.memfault.com/u/mastupristi)\ **Post date:** [February 18, 2020, 7:52am UTC](https://community.memfault.com/t/arm-none-eabi-nm-some-symbols-are-not-related-to-any-source-file/145/3 "2020-02-18T07:52:32Z")
of course: ```nohighlight /opt/gcc-arm-none-eabi-8-2019-q3-update/bin/arm-none-eabi-gcc \ -mcpu=cortex-m7 \ -mthumb \ -mapcs \ -mfloat-abi=hard \ -mfpu=fpv5-d16 \ -Wl,--gc-sections \ -Wl,--print-memory-usage \ -Wl,--sort-section=alignment \ -specs=nano.specs \ -nostartfiles \ -TDSP/dsp.ld \ -Wl,--cref,-Map=image/DSP.map \ -o image/DSP.elf \ ./build/DSP/amazon-freertos/lib/FreeRTOS-Plus-TCP/FreeRTOS_Sockets.o \ -L DSP \ -L CMSIS \ -larm_cortexM7lfsp_math \ -lm ``` However, I don’t think the problem is in the linking In fact I get the same output of arm-none-eabi-nm even if I analyse `./build/DSP/amazon-freertos/lib/FreeRTOS-Plus-TCP/FreeRTOS_Sockets.o`: ```nohighlight $ arm-none-eabi-nm -a -l -n -t x --print-size build/DSP/amazon-freertos/lib/FreeRTOS-Plus-TCP/FreeRTOS_Sockets.o | grep -E '^[[:xdigit:]]{8} [[:xdigit:]]{8} B' | grep SocketsList 00000000 00000014 B xBoundTCPSocketsList 00000000 00000014 B xBoundUDPSocketsList /home/max/Lavori/4202/src/repos/toremove/FW/amazon-freertos/lib/FreeRTOS-Plus-TCP/FreeRTOS_Sockets.c:162 ``` best regards ---
**Author:** ![francois](https://avatars.discourse-cdn.com/v4/letter/f/77aa72/32.png) [@francois](https://community.memfault.com/u/francois)\ **Post date:** [February 19, 2020, 12:14am UTC](https://community.memfault.com/t/arm-none-eabi-nm-some-symbols-are-not-related-to-any-source-file/145/4 "2020-02-19T00:14:03Z")
After looking a bit into this, we think you’ve hit a bug. The following very simple code reproduces it: ```auto #include extern int g_my_externd_global; int g_my_externd_global; int g_my_private_global; void main(void) { g_my_externd_global = 1; g_my_private_global = 1; while (1) {} } ``` Compiled with: ```auto arm-none-eabi-gcc -g3 -g -mcpu=cortex-m4 -mthumb -fdata-sections -nostdlib -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mthumb -g3 -nostdlib -ffunction-sections -fdata-sections -Os -fno-common -Wl,--gc-sections -Wl,-Map,build/example.map -Wl,-emain -Ttext=0x0 main.c -o build/example.elf ``` You can see the forward-declared variable does not have a file name: ```auto arm-none-eabi-nm -S -l build/example.elf 0001001c B __bss_end__ 00010014 B __bss_start 00010014 B __bss_start__ 00010014 T __data_start 0001001c B __end__ 0001001c B _bss_end__ 00010014 B _edata 0001001c B _end 00080000 N _stack 00010014 00000004 B g_my_externd_global 00010018 00000004 B g_my_private_global /Users/chrisc/dev/gcc_bug/main.c:5 00000000 00000014 T main /Users/chrisc/dev/gcc_bug/main.c:7 ``` Digging into the ELF data, we see that the DWARF information is missing a `DW_AT_decl_file` section for that symbol: ```auto <1><6f>: Abbrev Number: 4 (DW_TAG_variable) <70> DW_AT_name : (indirect string, offset: 0x3843): g_my_externd_global <74> DW_AT_decl_file : 1 <75> DW_AT_decl_line : 3 <76> DW_AT_decl_column : 12 <77> DW_AT_type : <0x61> <7b> DW_AT_external : 1 <7b> DW_AT_declaration : 1 <1><7b>: Abbrev Number: 5 (DW_TAG_variable) <7c> DW_AT_specification: <0x6f> <80> DW_AT_decl_line : 4 <81> DW_AT_decl_column : 5 <82> DW_AT_location : 5 byte block: 3 14 0 1 0 (DW_OP_addr: 10014) <1><88>: Abbrev Number: 6 (DW_TAG_variable) <89> DW_AT_name : (indirect string, offset: 0x234): g_my_private_global <8d> DW_AT_decl_file : 1 <8e> DW_AT_decl_line : 5 <8f> DW_AT_decl_column : 5 <90> DW_AT_type : <0x61> <94> DW_AT_external : 1 <94> DW_AT_location : 5 byte block: 3 18 0 1 0 (DW_OP_addr: 10018) ``` To me, this is a bug. Either: (A) `gcc` should be emitting the `DW_AT_decl_file` entry, but does not. or (B) `nm` should be able to work out the file by using the `DW_AT_specification` entry and using the same file as the forward declaration. Edit: We strongly suspect (B) is the bug. I suggest you open a bug against GNU binutils. ---
**Author:** ![mastupristi](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.memfault.com/mastupristi/32/32_2.png) [@mastupristi](https://community.memfault.com/u/mastupristi)\ **Post date:** [February 20, 2020, 9:42pm UTC](https://community.memfault.com/t/arm-none-eabi-nm-some-symbols-are-not-related-to-any-source-file/145/5 "2020-02-20T21:42:44Z")
Sorry to ask you maybe stupid questions, but I want to make sure I got this right. I’ve tried the same example as yours less than `#include ` I see this: ```nohighlight <1><29>: Abbrev Number: 2 (DW_TAG_variable) <2a> DW_AT_name : (indirect string, offset: 0x2b16): g_my_externd_global <2e> DW_AT_decl_file : 1 <2f> DW_AT_decl_line : 2 <30> DW_AT_decl_column : 12 <31> DW_AT_type : <0x35> <35> DW_AT_external : 1 <35> DW_AT_declaration : 1 <1><35>: Abbrev Number: 3 (DW_TAG_base_type) <36> DW_AT_byte_size : 4 <37> DW_AT_encoding : 5 (signed) <38> DW_AT_name : int <1><3c>: Abbrev Number: 4 (DW_TAG_variable) <3d> DW_AT_specification: <0x29> <41> DW_AT_decl_line : 3 <42> DW_AT_decl_column : 5 <43> DW_AT_location : 5 byte block: 3 14 0 1 0 (DW_OP_addr: 10014) <1><49>: Abbrev Number: 5 (DW_TAG_variable) <4a> DW_AT_name : (indirect string, offset: 0x1cb): g_my_private_global <4e> DW_AT_decl_file : 1 <4f> DW_AT_decl_line : 4 <50> DW_AT_decl_column : 5 <51> DW_AT_type : <0x35> <55> DW_AT_external : 1 <55> DW_AT_location : 5 byte block: 3 18 0 1 0 (DW_OP_addr: 10018) ``` I’ll try dissecting, starting from `g_my_private_global` @ line 4: ```auto int g_my_private_global; ``` and the dwarf infos related to it are: ```nohighlight <1><49>: Abbrev Number: 5 (DW_TAG_variable) <4a> DW_AT_name : (indirect string, offset: 0x1cb): g_my_private_global <4e> DW_AT_decl_file : 1 <4f> DW_AT_decl_line : 4 <================== <50> DW_AT_decl_column : 5 <51> DW_AT_type : <0x35> <55> DW_AT_external : 1 <55> DW_AT_location : 5 byte block: 3 18 0 1 0 (DW_OP_addr: 10018) ``` here is the name in the field `DW_AT_name`, a reference to a file (`DW_AT_decl_file : 1`), and also the address `0x10018` that match the `nm` output: ```nohighlight 00010018 B g_my_private_global /tmp/example/main.c:4 ``` Then lets see at `g_my_externd_global` @ lines 2 and 3: ```auto extern int g_my_externd_global; int g_my_externd_global; ``` and the dwarf infos related to it are: ```nohighlight <1><29>: Abbrev Number: 2 (DW_TAG_variable) <2a> DW_AT_name : (indirect string, offset: 0x2b16): g_my_externd_global <2e> DW_AT_decl_file : 1 <2f> DW_AT_decl_line : 2 <================== <30> DW_AT_decl_column : 12 <31> DW_AT_type : <0x35> <35> DW_AT_external : 1 <35> DW_AT_declaration : 1 <1><3c>: Abbrev Number: 4 (DW_TAG_variable) <3d> DW_AT_specification: <0x29> <41> DW_AT_decl_line : 3 <================= <42> DW_AT_decl_column : 5 <43> DW_AT_location : 5 byte block: 3 14 0 1 0 (DW_OP_addr: 10014) ``` the first block is almost identical to the `g_my_private_global`'s one except for the lack of ` DW_AT_location` replaced by `DW_AT_declaration`. Is this the point? The `DW_AT_location` is in the following block, where there is no `DW_AT_name` or `DW_AT_decl_file`, but there is `DW_AT_location` (with the actual address `0x10014), and `DW\_AT\_specification` which to me seems to refer to block above. Is all this reasoning correct? What is the sequence of steps that should be performed by `nm`? I mean: `nm` writes both address and name of the variable. So somehow it already reads and correlates the two blocks. If I understand correctly, what it doesn’t do is to use the file information `DW_AT_decl_file` from the first block, right? Or is GCC that should populate with another `DW_AT_decl_file` field the second block? Before opening a bug report I would like to be sure that there are no `nm` parameters (and other binutils tools) for this purpose. best regards Max ---
**Author:** ![francois](https://avatars.discourse-cdn.com/v4/letter/f/77aa72/32.png) [@francois](https://community.memfault.com/u/francois)\ **Post date:** [February 20, 2020, 11:43pm UTC](https://community.memfault.com/t/arm-none-eabi-nm-some-symbols-are-not-related-to-any-source-file/145/6 "2020-02-20T23:43:08Z")
Hi @mastupristi, I think you’ve got this right. `nm` should be looking at `<3c>`, and it should follow the `SW_AT_specification` to go find the `DW_AT_decl_file` under `<29>` to show the filename. This is my understanding of how it should work, but clearly it does not. Best, François. ---
**Author:** ![mastupristi](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.memfault.com/mastupristi/32/32_2.png) [@mastupristi](https://community.memfault.com/u/mastupristi)\ **Post date:** [February 21, 2020, 4:03pm UTC](https://community.memfault.com/t/arm-none-eabi-nm-some-symbols-are-not-related-to-any-source-file/145/7 "2020-02-21T16:03:31Z")
I noticed another oddity. Let’s take the following file for reference: ```auto extern int g_my_externd_global; int g_my_externd_global; int g_my_private_global; int main(void) { g_my_externd_global=1; g_my_private_global=1; return 0; } ``` I compile with `-Og`, no link: ```nohighlight max@resfw04:~/Lavori/4202/prog/test-dwarf$ arm-none-eabi-gcc -g3 -g -mthumb -mcpu=cortex-m4 -nostdlib -ffunction-sections -fdata-sections -Og -fno-common -c main.c -o example.o max@resfw04:~/Lavori/4202/prog/test-dwarf$ arm-none-eabi-nm -s -l example.o |grep _global 00000000 B g_my_externd_global 00000000 B g_my_private_global /home/max/Lavori/4202/prog/test-dwarf/main.c:3 max@resfw04:~/Lavori/4202/prog/test-dwarf$ arm-none-eabi-objdump --dwarf=info example.o example.o: file format elf32-littlearm Contents of the .debug_info section: Compilation Unit @ offset 0x0: Length: 0x6e (32-bit) Version: 4 Abbrev Offset: 0x0 Pointer Size: 4 <0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_producer : (indirect string, offset: 0x6ac): GNU C17 8.2.1 20181213 (release) [gcc-8-branch revision 267074] -mthumb -mcpu=cortex-m4 -mfloat-abi=soft -march=armv7e-m -g3 -g -O0 -ffunction-sections -fdata-sections -fno-common <10> DW_AT_language : 12 (ANSI C99) <11> DW_AT_name : (indirect string, offset: 0x116): main.c <15> DW_AT_comp_dir : (indirect string, offset: 0x880): /home/max/Lavori/4202/prog/test-dwarf <19> DW_AT_ranges : 0x0 <1d> DW_AT_low_pc : 0x0 <21> DW_AT_stmt_list : 0x0 <25> DW_AT_GNU_macros : 0x0 <1><29>: Abbrev Number: 2 (DW_TAG_variable) <2a> DW_AT_name : (indirect string, offset: 0x2aa9): g_my_externd_global <2e> DW_AT_decl_file : 1 <2f> DW_AT_decl_line : 1 <30> DW_AT_decl_column : 12 <31> DW_AT_type : <0x35> <35> DW_AT_external : 1 <35> DW_AT_declaration : 1 <1><35>: Abbrev Number: 3 (DW_TAG_base_type) <36> DW_AT_byte_size : 4 <37> DW_AT_encoding : 5 (signed) <38> DW_AT_name : int <1><3c>: Abbrev Number: 4 (DW_TAG_variable) <3d> DW_AT_specification: <0x29> <41> DW_AT_decl_line : 2 <42> DW_AT_decl_column : 5 <43> DW_AT_location : 5 byte block: 3 0 0 0 0 (DW_OP_addr: 0) <1><49>: Abbrev Number: 5 (DW_TAG_variable) <4a> DW_AT_name : (indirect string, offset: 0x1d3): g_my_private_global <4e> DW_AT_decl_file : 1 <4f> DW_AT_decl_line : 3 <50> DW_AT_decl_column : 5 <51> DW_AT_type : <0x35> <55> DW_AT_external : 1 <55> DW_AT_location : 5 byte block: 3 0 0 0 0 (DW_OP_addr: 0) <1><5b>: Abbrev Number: 6 (DW_TAG_subprogram) <5c> DW_AT_external : 1 <5c> DW_AT_name : (indirect string, offset: 0x2448): main <60> DW_AT_decl_file : 1 <61> DW_AT_decl_line : 4 <62> DW_AT_decl_column : 5 <63> DW_AT_prototyped : 1 <63> DW_AT_type : <0x35> <67> DW_AT_low_pc : 0x0 <6b> DW_AT_high_pc : 0x24 <6f> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) <71> DW_AT_GNU_all_call_sites: 1 <1><71>: Abbrev Number: 0 ``` But if I compile with `-O0`: ```nohighlight max@resfw04:~/Lavori/4202/prog/test-dwarf$ arm-none-eabi-gcc -g3 -g -mthumb -mcpu=cortex-m4 -nostdlib -ffunction-sections -fdata-sections -O0 -fno-common -c main.c -o example.o max@resfw04:~/Lavori/4202/prog/test-dwarf$ arm-none-eabi-nm -s -l example.o |grep _global 00000000 B g_my_externd_global /home/max/Lavori/4202/prog/test-dwarf/main.c:1 00000000 B g_my_private_global /home/max/Lavori/4202/prog/test-dwarf/main.c:3 max@resfw04:~/Lavori/4202/prog/test-dwarf$ arm-none-eabi-objdump --dwarf=info example.o example.o: file format elf32-littlearm Contents of the .debug_info section: Compilation Unit @ offset 0x0: Length: 0x6e (32-bit) Version: 4 Abbrev Offset: 0x0 Pointer Size: 4 <0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_producer : (indirect string, offset: 0x1b68): GNU C17 8.2.1 20181213 (release) [gcc-8-branch revision 267074] -mthumb -mcpu=cortex-m4 -mfloat-abi=soft -march=armv7e-m -g3 -g -Og -ffunction-sections -fdata-sections -fno-common <10> DW_AT_language : 12 (ANSI C99) <11> DW_AT_name : (indirect string, offset: 0x116): main.c <15> DW_AT_comp_dir : (indirect string, offset: 0x7d9): /home/max/Lavori/4202/prog/test-dwarf <19> DW_AT_ranges : 0x0 <1d> DW_AT_low_pc : 0x0 <21> DW_AT_stmt_list : 0x0 <25> DW_AT_GNU_macros : 0x0 <1><29>: Abbrev Number: 2 (DW_TAG_variable) <2a> DW_AT_name : (indirect string, offset: 0x2aa8): g_my_externd_global <2e> DW_AT_decl_file : 1 <2f> DW_AT_decl_line : 1 <30> DW_AT_decl_column : 12 <31> DW_AT_type : <0x35> <35> DW_AT_external : 1 <35> DW_AT_declaration : 1 <1><35>: Abbrev Number: 3 (DW_TAG_base_type) <36> DW_AT_byte_size : 4 <37> DW_AT_encoding : 5 (signed) <38> DW_AT_name : int <1><3c>: Abbrev Number: 4 (DW_TAG_variable) <3d> DW_AT_specification: <0x29> <41> DW_AT_decl_line : 2 <42> DW_AT_decl_column : 5 <43> DW_AT_location : 5 byte block: 3 0 0 0 0 (DW_OP_addr: 0) <1><49>: Abbrev Number: 5 (DW_TAG_variable) <4a> DW_AT_name : (indirect string, offset: 0x1d3): g_my_private_global <4e> DW_AT_decl_file : 1 <4f> DW_AT_decl_line : 3 <50> DW_AT_decl_column : 5 <51> DW_AT_type : <0x35> <55> DW_AT_external : 1 <55> DW_AT_location : 5 byte block: 3 0 0 0 0 (DW_OP_addr: 0) <1><5b>: Abbrev Number: 6 (DW_TAG_subprogram) <5c> DW_AT_external : 1 <5c> DW_AT_name : (indirect string, offset: 0x2447): main <60> DW_AT_decl_file : 1 <61> DW_AT_decl_line : 4 <62> DW_AT_decl_column : 5 <63> DW_AT_prototyped : 1 <63> DW_AT_type : <0x35> <67> DW_AT_low_pc : 0x0 <6b> DW_AT_high_pc : 0x18 <6f> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) <71> DW_AT_GNU_all_call_sites: 1 <1><71>: Abbrev Number: 0 ``` therefore with `-O0` the file name information is correctly recovered and displayed by `nm`. Instead with `-Og` the problem occurs. However, the debug information is not so different as to justify this behavior. ![nm](https://canada1.discourse-cdn.com/flex030/uploads/memfault/original/1X/df71762cd929ada592379d4b76d97a6e4a177998.png) The problem must be somewhere else. best regards Max ---
**Author:** ![francois](https://avatars.discourse-cdn.com/v4/letter/f/77aa72/32.png) [@francois](https://community.memfault.com/u/francois)\ **Post date:** [February 22, 2020, 5:33am UTC](https://community.memfault.com/t/arm-none-eabi-nm-some-symbols-are-not-related-to-any-source-file/145/8 "2020-02-22T05:33:57Z")
Hmmm, that’s an interesting result. It’s clear to me this is a bug, but I’m not sure whether it is on the `nm` or `gcc` side. ---
**Author:** ![chrisc](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.memfault.com/chrisc/32/22_2.png) [@chrisc](https://community.memfault.com/u/chrisc)\ **Post date:** [February 23, 2020, 4:06pm UTC](https://community.memfault.com/t/arm-none-eabi-nm-some-symbols-are-not-related-to-any-source-file/145/9 "2020-02-23T16:06:18Z")
Ultimately, the problem looks very similar to the one fixed for functions [here](https://github.com/bminor/binutils-gdb/commit/422f3d3d6d5713bf9235b7b7696818a70b3b578d). Notice how in the [variable block](https://github.com/bminor/binutils-gdb/blob/986f078366b193ed9f5bd02af965f3af958ba859/bfd/dwarf2.c#L3348-L3403) there is no traversal of the `DW_AT_specification` attribute. I believe an update will need to be made to the switch case there to fix the recovery of line information for some global variables. > 00000000 B g\_my\_externd\_global /home/max/Lavori/4202/prog/test-dwarf/main.c:1 > 00000000 B g\_my\_private\_global /home/max/Lavori/4202/prog/test-dwarf/main.c:3 It’s the interaction of ` -fno-common` (handling for tentative definitions) and the optimization setting (`-Og` vs `-O0`) that are controlling whether the variable is allocated in the .o or not. If you remove `-fno-common`, you would see no line info for either global in the .o debug info. Best, Chris ---
**Author:** ![mastupristi](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.memfault.com/mastupristi/32/32_2.png) [@mastupristi](https://community.memfault.com/u/mastupristi)\ **Post date:** [March 21, 2020, 8:36pm UTC](https://community.memfault.com/t/arm-none-eabi-nm-some-symbols-are-not-related-to-any-source-file/145/10 "2020-03-21T20:36:45Z")
> [@francois](#): > > We strongly suspect (B) is the bug. I suggest you open a bug against GNU binutils. I opened a [bug](https://sourceware.org/bugzilla/show_bug.cgi?id=25676) on the binutils’ bugzilla. A patch was pushed on master that I tried on both x86 and ARM (recompiling the toolchain arm-none-eabi). I published the [results](https://sourceware.org/bugzilla/show_bug.cgi?id=25676#c5). This new `nm` works in almost all cases but fails to retrieve file names only for object files compiled with `-fcommon`, while the related elf files are OK. So I assume there is still something to fix. In the report I’ve attached also the [python script](https://sourceware.org/bugzilla/attachment.cgi?id=12392) I used to do the tests best regards Max ---
**Author:** ![francois](https://avatars.discourse-cdn.com/v4/letter/f/77aa72/32.png) [@francois](https://community.memfault.com/u/francois)\ **Post date:** [March 23, 2020, 6:27pm UTC](https://community.memfault.com/t/arm-none-eabi-nm-some-symbols-are-not-related-to-any-source-file/145/11 "2020-03-23T18:27:56Z")
Awesome to see it got fixed! In the case of symbols in the `COMMON` section, I can imagine why it’s tricky: they may have multiple definitions so it’s not clear which to display.