Thanks Brian,
That helps to clarify what was the root cause, so now we can deal with it.
Regards,
Burt
Brian Dessent wrote:
Burt Bicksler wrote:
We have tracked the difference down to the following line in the
assembly code that is emited:
<_GLOBAL__I_software_foo_fah_snmp_AFSecZoneMib.cpp_8D2A3925_B0CAE5BA>:
You can use c++filt to help you here:
$ echo
'_GLOBAL__I_software_foo_fah_snmp_AFSecZoneMib.cpp_8D2A3925_B0CAE5BA' |
c++filt
global constructors keyed to
software_foo_fah_snmp_AFSecZoneMib.cpp_8D2A3925_B0CAE5BA
So this is the name of a function that runs static constructors for some
object in AFSecZoneMib.cpp. It's been uniquified so that it can't clash
with any other object in the link from any other TU.
The last four HEX bytes, B0CAE5BA, are what is different on each run.
The rest of the line is the same.
Searching around Google hasn't turned up too much information yet. One
reference was to a global constructor tag, but there was no mention of
how the suffix is derived. Not sure if this has anything to do with the
anonymous namespace suggestion made earlier. I think that we'll try the
-frandom-seed switch to see if that will do it, since the description
there says "certain" symbol names that have to be different...
Look at gcc/tree.c:get_file_function_name(). The first group is a CRC32
of the object name and the second is a CRC32 of some randomness, so in
other words -frandom-seed is what you need.
Brian
