This is the mail archive of the
mailing list for the GCC project.
Re: gcc-4.9.1 generating different code between two successive builds
- From: Cole <cole at opteqint dot net>
- To: Andrew Haley <aph at redhat dot com>
- Cc: Georg-Johann Lay <avr at gjlay dot de>, gcc at gcc dot gnu dot org
- Date: Thu, 31 Dec 2015 17:29:17 +0200
- Subject: Re: gcc-4.9.1 generating different code between two successive builds
- Authentication-results: sourceware.org; auth=none
- References: <CACsf_wwETk+L6eq0HoL0Hz8sa-CZdntZVtjGk4aY8D1989vMqw at mail dot gmail dot com> <5683F967 dot 4090309 at gjlay dot de> <568500AC dot 6010706 at redhat dot com>
I will investigate next week, and have a look at whether ASLR is
turned off in our build system. But if it was on, I would expect more
than a single .o file to be different.
At this point in time, by disabling libcilkrts, and one other option,
I can't remember which right now, I can get gcc building reproducibly.
With regards to the libcilkrts library, there is only a single .o file
that is being generated that differs each time. When running it
through objdump, the differences always seem to pop up in the same
function if I am not mistaken, and the actual assembly generated
differs. Normally from the very beginning of the register
On 31 December 2015 at 12:17, Andrew Haley <firstname.lastname@example.org> wrote:
> On 30/12/15 15:33, Georg-Johann Lay wrote:
>> Some parts of the compiler use the address of objects to compute
>> hashes, but I don't remember which part(s) actually do this. That
>> technique can lead to different code for different runs of the
>> compiler even on the same system. This is hard to reproduce as it
>> depends on how the OS is supplying memory, and it might depend on
>> the "history" of the machine and the actual OS.
> ... and many Linux kernels deliberately randomize memory layout to
> provide some protection from buffer overflow attacks.