x_gcc-help_x@xxxxxxxxxxxxxxxxxxxxx writes: > By inspecting .o and .elf files with "nm" I can see that gcc appends > .NNNN to the symbol names for some variables. > > Is there somewhere I can read more about this? Not that I'm aware of. > Afaict, gcc only appends the .NNNN suffix for static variables, and it > uses a unique number for each variable, but the actual number may also > vary depending on the existence of non-static globals. Yes. The number is gcc's internal UID for the variable. The UID value is incremented approximately for each name that gcc sees. It is also incremented when making a copy of the variable, which means that it is affected by optimization. > The reason for asking is I am investigating some problems with a build > and by using "nm" to inspect the .o and .elf files I discovered a > discrepancy:- > > $ nm -lS foo.o > foo.nm > $ nm -lS bar.elf > bar.nm > $ grep -E '\.[0-9]+$' foo.nm bar.nm > foo.nm:00000000 00000002 b BCast_count.3756 > foo.nm:00000000 00000004 b LEDstate.4115 > foo.nm:00000000 00000004 d current_state.3953 > foo.nm:00000000 00000002 b oldTime.4114 > foo.nm:00000000 00000004 b previous_sample.3951 > foo.nm:00000000 00000001 d sample_count.3952 > bar.nm:20000068 00000002 b BCast_count.3759 > bar.nm:2000005c 00000004 b LEDstate.4118 > bar.nm:20000004 00000004 d current_state.3956 > bar.nm:20000060 00000002 b oldTime.4117 > bar.nm:20000064 00000004 b previous_sample.3954 > bar.nm:20000008 00000001 d sample_count.3955 > > As you see, the suffixes used in the .elf file are offset by 3 from > those in the .o file. I don't know what a .elf file is. If a .elf file is a binary linked from the .o file, then I think you have demonstrated that that .elf file was not linked from that .o file. The symbol name is set by the compiler, but it is not changed by the assembler or linker. Ian
