Different object code generated each time file is compiled

Different object code generated each time file is compiled

[Burt Bicksler]

Hi,

We are build for a MIPS32 target using a GCC cross compiler, and we have 
two object files that are always different each time they are built with 
no changes to the source code.  We have used the -E switch to generate 
pre-processor output and compared the pre-processor output from each run 
against each other.

They pre-processor output from each run is the same.  So it appears for 
these two source files that the issue with the object code being 
generated differing comes from the compiler.  It is the object files 
before linking that are different (as well as the resulting final 
binaries but we have tracked it back to the object files emitted by the 
compiler as the first point where the files differ.

It is only two source files that we see this difference with and it is 
always 4 bytes in each object file that is different.

Has anyone encountered anything like this before?

Note that the resulting code always seems to execute just fine.  This 
would not be an issue except that we have a requirement to be able to 
validate that the code produced from a given revision of the source code 
always produces a binary identical executable, and this issue is causing 
some head scratching.

Thanks,
Burt

Re: Different object code generated each time file is compiled

[Kai Henningsen]

On Tue, 30 Sep 2008 16:27:31 -0400
Burt Bicksler <bbicksler@fortresstech.com> wrote:

> It is only two source files that we see this difference with and it
> is always 4 bytes in each object file that is different.

I suggest that you look at the assembler source, either by compiling
with -s (so that only assembler is produced) or with -save-temps (so
that the assembler source isn't deleted after being used to produce the
object code). By comparing the .s files, you should be able to identify
what changes.

RE: Different object code generated each time file is compiled

[Young, Michael]

I'm assuming you're talking about compiled object files that aren't yet
linked... Correct?  Most link formats have link-time information (such
as timestamps and such) inserted into the files.
  - Mike 

-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
Behalf Of Burt Bicksler
Sent: Tuesday, September 30, 2008 4:28 PM
To: gcc-help@gcc.gnu.org
Subject: Different object code generated each time file is compiled

Hi,

We are build for a MIPS32 target using a GCC cross compiler, and we have
two object files that are always different each time they are built with
no changes to the source code.  We have used the -E switch to generate
pre-processor output and compared the pre-processor output from each run
against each other.

They pre-processor output from each run is the same.  So it appears for
these two source files that the issue with the object code being
generated differing comes from the compiler.  It is the object files
before linking that are different (as well as the resulting final
binaries but we have tracked it back to the object files emitted by the
compiler as the first point where the files differ.

It is only two source files that we see this difference with and it is
always 4 bytes in each object file that is different.

Has anyone encountered anything like this before?

Note that the resulting code always seems to execute just fine.  This
would not be an issue except that we have a requirement to be able to
validate that the code produced from a given revision of the source code
always produces a binary identical executable, and this issue is causing
some head scratching.

Thanks,
Burt

Re: Different object code generated each time file is compiled

[Brian Dessent]

Burt Bicksler wrote:

> It is only two source files that we see this difference with and it is
> always 4 bytes in each object file that is different.
> 
> Has anyone encountered anything like this before?

There are several things that can cause this.  The most common is the
use of the __TIME__ or __DATE__ macros, however this doesn't seem
applicable in your case if you are compiling preprocessed source since
the expansion will have already occurred.

Another less obvious source of differences are anonymous namespaces. 
Because the standard says that they must be unique to each translation
unit, the compiler has to add some random strings to their mangled names
to uniquify them so that no two can clash.  The -frandom-seed option is
provided as a way for the user to specify their own uniquifier string:
<http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#index-frandom_002dstring-571>

If that doesn't cover your problem then you'll probably have to
investigate further.  Try diffing the assembler output (-S) of two runs
and the source of the difference should jump out at you.

Brian

Re: Different object code generated each time file is compiled

[Burt Bicksler]

Thanks Brian,

That's one I hadn't thought of, the anonymous name spaces.

I already have the developer working on diffing the assembler output
so that should tell us something too.

Regards,
Burt

Brian Dessent wrote:
> Burt Bicksler wrote:
>
>   
>> It is only two source files that we see this difference with and it is
>> always 4 bytes in each object file that is different.
>>
>> Has anyone encountered anything like this before?
>>     
>
> There are several things that can cause this.  The most common is the
> use of the __TIME__ or __DATE__ macros, however this doesn't seem
> applicable in your case if you are compiling preprocessed source since
> the expansion will have already occurred.
>
> Another less obvious source of differences are anonymous namespaces. 
> Because the standard says that they must be unique to each translation
> unit, the compiler has to add some random strings to their mangled names
> to uniquify them so that no two can clash.  The -frandom-seed option is
> provided as a way for the user to specify their own uniquifier string:
> <http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#index-frandom_002dstring-571>
>
> If that doesn't cover your problem then you'll probably have to
> investigate further.  Try diffing the assembler output (-S) of two runs
> and the source of the difference should jump out at you.
>
> Brian
>   

Re: Different object code generated each time file is compiled

[Burt Bicksler]

Thanks to everyone who replied to my earlier question.

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>:

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...

Regards,
Burt

Re: Different object code generated each time file is compiled

[Brian Dessent]

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

Configure and make only CC1 ??

[duongtu]

Hi All, 

I have searched for the configuration and make command for building just only cc1 (Because I would like to investigate only CC1). 
If someone have the answer (Can or cannot), please let me know!

Regards,
Tu

Re: Different object code generated each time file is compiled

[Burt Bicksler]

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
>   

Re: Configure and make only CC1 ??

[Ian Lance Taylor]

"duongtu" <duongtu@gmail.com> writes:

> I have searched for the configuration and make command for building just only cc1 (Because I would like to investigate only CC1). 
> If someone have the answer (Can or cannot), please let me know!

When you run configure, use the option --enable-languages=c.

Ian

Re: Configure and make only CC1 ??

[Tu]

Hi Ian,

Thanks for your suggest,
But what I mention here is not the languages, for my purpose, I want
to build GCC just only the compiler (CC1) without the linker or orther
execute outputs (xgcc)

Regards,
Tu

On Wed, Oct 1, 2008 at 10:22 PM, Ian Lance Taylor <iant@google.com> wrote:
>
> "duongtu" <duongtu@gmail.com> writes:
>
> > I have searched for the configuration and make command for building just only cc1 (Because I would like to investigate only CC1).
> > If someone have the answer (Can or cannot), please let me know!
>
> When you run configure, use the option --enable-languages=c.
>
> Ian



--
Try to smart, Hard to work

Re: Configure and make only CC1 ??

[Ian Lance Taylor]

Tu <duongtu@gmail.com> writes:

> Thanks for your suggest,
> But what I mention here is not the languages, for my purpose, I want
> to build GCC just only the compiler (CC1) without the linker or orther
> execute outputs (xgcc)

I'm not sure why you want to do that, but doing something like this
would do it:

configure <options> --disable-bootstrap --enable-languages=c
make all-gcc
^C when it goes into the gcc directory
cd gcc
make cc1

Ian

RE: Configure and make only CC1 ??

[duongtu]

Hi Ian,

Thanks for your support!
I want to do that because I just want to use CC1 for investigating (debug cc1 only). I would consider your way :)

Regards,
Tu

-----Original Message-----
From: Ian Lance Taylor [mailto:iant@google.com] 
Sent: Thursday, October 02, 2008 1:24 AM
To: Tu
Cc: gcc-help@gcc.gnu.org
Subject: Re: Configure and make only CC1 ??

Tu <duongtu@gmail.com> writes:

> Thanks for your suggest,
> But what I mention here is not the languages, for my purpose, I want
> to build GCC just only the compiler (CC1) without the linker or orther
> execute outputs (xgcc)

I'm not sure why you want to do that, but doing something like this
would do it:

configure <options> --disable-bootstrap --enable-languages=c
make all-gcc
^C when it goes into the gcc directory
cd gcc
make cc1

Ian