binary reproducibility and c++ default allocators

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



GCC team,

At work, we use version 2.96 with Redhat Linux 7.3.  We work in an embedded industry that requires complete binary reproducibility (BR) of compiles so regulators may verify the source code reproduces the images they are given.  Consequently, we avoid anonymous namespaces and other known violators of reproducibility.

We have currently found a strange occurance BR breakage.  We have a file that is completely empty save for includes of headers (many headers through one main include).  The .o produced differs each build.  Tracing the translation unit through the build process has shown that the assembly output differs on a few lines related to allocators.

They have the format:

.stabs "_GLOBAL_.I._S_chunk_alloc__t24__default_alloc_template2b1i0UiRiSomefilepath.cppLyTUed:f(0,21)",36,0,1256,_GLOBAL_.I._S_chunk_alloc__t24__default_alloc_template2b1i0UiRiSomefilepath.cppLyTUed
        .type    _GLOBAL_.I._S_chunk_alloc__t24__default_alloc_template2b1i0UiRiSomefilepath.cppLyTUed,@function
_GLOBAL_.I._S_chunk_alloc__t24__default_alloc_template2b1i0UiRiSomefilepath.cppLyTUed:

This issue appears above some assembly that sets up a stack frame, calls __static_initialization_and_destruction_0, then resets the stack frame and returns, but I am not sure if that is relevant (I found some older messages which approached somewhat unrelated issues with static template members which made me think mentioning it might be helpful).

My main question is concerning the Somefilepath.cpp (fictitious here) that points to the compile path of the almost empty cpp and, in particular, the "LyTUed" sequence appended to the end.  That is the sequence which differs in each compile.  

I am trying to find out what is being done to cause this code to be generated so we know what to avoid in the future.  It is not simply use of the standard library, as vectors and strings are used throughout the code without any problems.  If anyone knows why the GUID characters and pathname are appended for these functions into the assembly output, it would really benefit my company.

galathaea

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux