How gcc appends .NNNN to static variables

[x_gcc-help_x@nospam.pz.podzone.net]

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