Hi, 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? 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. 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. This build was made on another machine that I do not have access to. If I rebuild from sources then the .NNNN suffixes *do* match between .o and .elf. I did suspect that the reason may be down to a build aborted through compile errors (the .elf being a stale file left over from a previous successful build). However the file time-stamps do not bear this theory out. The resulting binary when building locally does not match that shipped with the build (which is the issue I'm trying to resolve) although the binary difference may be due to other factors which are also under investigation. I'm stumped right now - and not helped by a lack of understanding in gcc's handling of those suffixes - so my question is do the above differences in .NNNN suffix have a plausible explanation or could they be indicative of some oddity in the build process, or maybe a source code error causing gcc to go screwy? Note: filenames changed to protect the innocent. Thanks! Charlie
