C6x CGT 7.4.1: different binaries after compilation

This wiki article shows you how to find the functions with the biggest code size increase.  You can collect the same the data the same way.  Just interpret the data a bit differently.  You are interested in any function with a code size difference.  That will tell you which function(s) to focus on.  Hopefully, it will be pretty straightforward from there.

Thanks and regards,

-George

Thanks! This helped to find the functions which get compiled differently between compiler runs (they are in two files)!!

But we haven't been able to create a testcase. When you extract those files into a small project, they always get compiled with the same result (.obj). But when built in the whole project, they are different.The customer hesitates to share the whole project with me, so it might be hard to get down to the root cause.

What could cause the compiler to generate different code? Looking at the generated disassembly it's clear that different code is generated for the affected functions!

Thanks,
  Robert

What is the nature of the difference?

After doing further test I now have a small test case that reproduces the issue!!

Attached two generated .asm files. Based on the same source code, but after two compiler runs. Look at line 4301. Different registers are used. If you look further down (line 4432), there is even different code.

I can provide the whole testcase if needed. To whom should I send it?

Thanks,
  Robert

EDIT: Attachment removed. Follow up will be via ClearQuest.

I used the following compilation commands extracted from your makefile to compile with 7.4.1 on Linux for 2 times, I can not find any differences in the generated .asm file. The only differences are the timestamp encoded in some labels. Those should not be counted as meaningful difference.

Here are the compilation commands:

cl6x -mv6740 --abi=coffabi -O3 -g --define=dm8148 --display_error_number --diag_warning=225 --diag_wrap=off --speculate_loads=50 --debug_software_pipeline --optimizer_interlist -k --preproc_with_compile --preproc_dependency="objs.pp" objs_lf.c
cl6x -mv6740 --abi=coffabi -O3 -g --define=dm8148 --display_error_number --diag_warning=225 --diag_wrap=off --speculate_loads=50 --debug_software_pipeline --optimizer_interlist -k --preproc_with_compile --preproc_dependency="objs.pp" objs.c

Can you just try these commands to see if you can reproduce some differences on your side. Then we can go from there. Either the commands I used are different from yours or there is something in ENV which causes the trouble.

Wei

Wei,

Two compiler runs are not enough. Sometimes I had to run the compiler 15 times until a different .asm was generated. I've tried this command line, exactly same options as you have (I've added include directory in command line), but on a Windows 7 machine:

\ti\ccsv5\tools\compiler\c6000_7.4.1\bin\cl6x -mv6740 --abi=coffabi -O3 -g --define=dm8148 --display_error_number --diag_warning=225 --diag_wrap=off --speculate_loads=50 --debug_software_pipeline --optimizer_interlist -k --preproc_with_compile --include_path="C:/ti/ccsv5/tools/compiler/c6000_7.4.1/include"  --preproc_dependency="objs.pp" objs_lf.c

The resulting objs_lf.asm was most times 501,324 bytes in size, but often in different size.

I've used a batch file to automatically recompile and print the .asm size. Attached the result.

Thanks,
  Robert

I now can reproduce your problem.

It can only be reproduced on PC, my system is win7.

As to the size of the asm file, the standard is 501,159. The out of normal size could be different, I got the following: 512940, 503533 And these out of normal size can also be reproduced.

I wonder the priority of this bug, can you tell me?

Wei 

Wei,

It's a critical issue for them. Different teams at different locations are working on the same project. They need to be sure if the files are compiled, that the same object code is generated every time (to be sure the code behaves the same). 

Thanks,
  Robert

Robert,

Now I understand. I will put a high priority on it.

For the time being, if your customer wants to go ahead, you can tell them to use the LINUX version. This problem seems only happens on PC tools. If they don't use LINUX, then they have to wait and we will have it fixed ASAP.

Wei 

Wei,

Do we know the root cause already? My customer asked if there is any workaround they can use. Maybe change one line of critical code?

Thanks,
  Robert

Robert,

I passed your request on.

Wei

The cause of the problem is that a couple of hash functions are using the addresses of objects, and those codes sometimes influence the order of operations.  Modern operating systems use address-space layout randomisation (ASLR) as a security technique -- it makes it harder for malicious code to exploit vulnerabilities, because they aren't always in the same place.  Combine the use of addresses with the fact that addresses are sometimes different, and we have the problem:  that repeated runs sometimes produce different answers.

We have a patch for the problem, but the only workaround we know for sure is to disable ASLR.  On Linux, one can do "setarch `uname -m` -R ./cmd" to disable it for the single command "./cmd".  I'm told that kernels before 2.6.12 don't have ASLR, so using an old Linux may be another workaround.

On Windows, there is apparently a registry key that will disable ASLR for the entire system.  Windows 7 has an Enhanced Mitigation Experience Toolkit, from Microsoft;  someone claims that the registry key doesn't do it for Windows 7.  I have no experience with Windows and can't confirm that this works.

Robert Finger said:

Is a fix already available?

Yes.  It is fixed in release 7.4.4.

Thanks and regards,

-George