I am compiling legacy code that calculates color spectra using linear algebra. The matrices use float as the type, and all calculations use float. When we use our old compiler (turbo-linux gcc 2.95) we get one answer. When I use our new compiler (SuSE gcc 4.3.2) we get different spectra.
I need to get the output of the same program compiled using the new compiler to match the output using the old compiler.
I have tried using these compiler options:
g++ -g -lstdc++ -mfpmath=no-sse -mno-sse -mno-sse2 -ffloat-store -mieee-fp
and this code:
volatile unsigned short int cw;
__asm__ volatile("fstcw %0" : "=m" (*&cw));
printf("floating point control word was: %x\n",cw);
cw=0x027f;
__asm__ volatile("fldcw %0" :: "m" (*&cw));
printf("floating point control word now is: %x\n",cw);
None of this enabled the color spectra to match.
The question is then... is there a silver bullet to make the color spectra resulting from code compiled from the two different compilers to match? I was hoping the floating point control width (the flpcw above) was the solution, but it wasn't. (note, the code is too complex to post, ).
P.S. the result of the above code was:
gcc 2.95 floating point control word was: 0x37f
floating point control word now is 0x27f.
gcc 4.3.2 floating point control word was: 0x37f
floating point control word now is 0x27f.
Related
My project sometimes benefits from ccache, so I have long been using ccache. I'm now adding precompiled headers. Some sources suggest that the two are incompatible and that one must choose between them. But I find in ccache's documentation that it does support PCH on some level: https://ccache.samba.org/manual.html#_precompiled_headers
Indeed, when I try using ccache to build a .o file while using Clang's -include-pch option, I see that ccache is succeeding at caching the .o. The first compilation attempt takes 1.5 s, and a second takes only 0.05 s (because ccache has done its job).
The trouble is that if I run this same compilation command with clang++ instead of with /usr/lib/ccache/clang++, it takes 0.5 s... unless I leave off the -include-pch part, in which case it takes about 1.5 s. It seems that ccache may be causing my PCH to be ignored, or something.
I've followed the instructions (from the link above). As specified there, my ccache.conf looks like this:
sloppiness=pch_defines,time_macros
And I've tried every reasonable combination of #include, -include, -include-pch, and -fpch-preprocess I could think of. Compilation always takes 1.5 s and then 0.05 s, when it should take 0.5 s, and then 0.05 s.
Is it possible to make this work, or do I have to choose between ccache and PCH after all?
I used
readelf --dyn-sym my_elf_binary | grep FUNC | grep UND
to display the dynamically imported functions of my_elf_binary, from the dynamic symbol table in the .dynsym section to be precise. Example output would be:
[...]
3: 00000000 0 FUNC GLOBAL DEFAULT UND tcsetattr#GLIBC_2.0 (3)
4: 00000000 0 FUNC GLOBAL DEFAULT UND fileno#GLIBC_2.0 (3)
5: 00000000 0 FUNC GLOBAL DEFAULT UND isatty#GLIBC_2.0 (3)
6: 00000000 0 FUNC GLOBAL DEFAULT UND access#GLIBC_2.0 (3)
7: 00000000 0 FUNC GLOBAL DEFAULT UND open64#GLIBC_2.2 (4)
[...]
Is it safe to assume that the names associated to these symbols, e.g. the tcsetattr or access, are always unique? Or is it possible, or reasonable*), to have a dynamic symbol table (filtered for FUNC and UND) which contains two entries with the same associated string?
The reason I am asking is that I am looking for a unique identifier for dynamically imported functions ...
*) Wouldn't the dynamic linker resolve all "UND FUNC symbols" with the same name to the same function anyway?
Yes, given a symbol name and the set of libraries an executable is linked against, you can uniquely identify the function. This behavior is required for linking and dynamic linking to work.
An illustrative example
Consider the following two files:
librarytest1.c:
#include <stdio.h>
int testfunction(void)
{
printf("version 1");
return 0;
}
and librarytest2.c:
#include <stdio.h>
int testfunction(void)
{
printf("version 2");
return 0;
}
Both compiled into shared libraries:
% gcc -fPIC -shared -Wl,-soname,liblibrarytest.so.1 -o liblibrarytest.so.1.0.0 librarytest1.c -lc
% gcc -fPIC -shared -Wl,-soname,liblibrarytest.so.2 -o liblibrarytest.so.2.0.0 librarytest2.c -lc
Note that we cannot put both functions by the same name into a single shared library:
% gcc -fPIC -shared -Wl,-soname,liblibrarytest.so.0 -o liblibrarytest.so.0.0.0 librarytest1.c librarytest2.c -lc
/tmp/cctbsBxm.o: In function `testfunction':
librarytest2.c:(.text+0x0): multiple definition of `testfunction'
/tmp/ccQoaDxD.o:librarytest1.c:(.text+0x0): first defined here
collect2: error: ld returned 1 exit status
This shows that symbol names are unique within a shared library, but do not have to be among a set of shared libraries.
% readelf --dyn-syms liblibrarytest.so.1.0.0 | grep testfunction
12: 00000000000006d0 28 FUNC GLOBAL DEFAULT 10 testfunction
% readelf --dyn-syms liblibrarytest.so.2.0.0 | grep testfunction
12: 00000000000006d0 28 FUNC GLOBAL DEFAULT 10 testfunction
Now lets link our shared libraries with an executable. Consider linktest.c:
int testfunction(void);
int main()
{
testfunction();
return 0;
}
We can compile and link this against either shared library:
% gcc -o linktest1 liblibrarytest.so.1.0.0 linktest.c
% gcc -o linktest2 liblibrarytest.so.2.0.0 linktest.c
And run each of them (note I'm setting the dynamic library path so the dynamic linker can find the libraries, which are not in a standard library path):
% LD_LIBRARY_PATH=. ./linktest1
version 1%
% LD_LIBRARY_PATH=. ./linktest2
version 2%
Now lets link our executable to both libraries. Each is exporting the same symbol testfunction and each library has a different implementation of that function.
% gcc -o linktest0-1 liblibrarytest.so.1.0.0 liblibrarytest.so.2.0.0 linktest.c
% gcc -o linktest0-2 liblibrarytest.so.2.0.0 liblibrarytest.so.1.0.0 linktest.c
The only difference is the order the libraries are referenced to the compiler.
% LD_LIBRARY_PATH=. ./linktest0-1
version 1%
% LD_LIBRARY_PATH=. ./linktest0-2
version 2%
Here are the corresponding ldd output:
% LD_LIBRARY_PATH=. ldd ./linktest0-1
linux-vdso.so.1 (0x00007ffe193de000)
liblibrarytest.so.1 => ./liblibrarytest.so.1 (0x00002b8bc4b0c000)
liblibrarytest.so.2 => ./liblibrarytest.so.2 (0x00002b8bc4d0e000)
libc.so.6 => /lib64/libc.so.6 (0x00002b8bc4f10000)
/lib64/ld-linux-x86-64.so.2 (0x00002b8bc48e8000)
% LD_LIBRARY_PATH=. ldd ./linktest0-2
linux-vdso.so.1 (0x00007ffc65df0000)
liblibrarytest.so.2 => ./liblibrarytest.so.2 (0x00002b46055c8000)
liblibrarytest.so.1 => ./liblibrarytest.so.1 (0x00002b46057ca000)
libc.so.6 => /lib64/libc.so.6 (0x00002b46059cc000)
/lib64/ld-linux-x86-64.so.2 (0x00002b46053a4000)
Here we can see that while symbols are not unique, the way the linker resolves them is defined (it appears that it always resolves the first symbol it encounters). Note that this is a bit of a pathological case as you normally wouldn't do this. In the cases where you would go this direction there are better ways of handling symbol naming so they would be unique when exported (symbol versioning, etc)
In summary, yes, you can uniquely identify the function given its name. If there happens to be multiple symbols by that name, you identify the proper one using the order the libraries are resolved in (from ldd or objdump, etc). Yes, in this case you need a bit more information that just its name, but it is possible if you have the executable to inspect.
Note that in your case, the name of the first function import is not just tcsetattr but tcsetattr#GLIBC_2.0. The # is how the readelf program displays a versioned symbol import.
GLIBC_2.0 is a version tag that glibc uses to stay binary compatible with old binaries in the (unusual but possible) case that the binary interface to one of its functions needs to change. The original .o file produced by the compiler will just import tcsetattr with no version information but during static linking, the linker has noticed that the actual symbol exported by lic.so carries a GLIBC_2.0 tag, and so it creates a binary that insists on importing the particular tcsetattr symbol that has version GLIBC_2.0.
In the future there might be a libc.so that exports one tcsetattr#GLIBC_2.0 and a different tcsetattr#GLIBC_2.42, and the version tag will then be used to find which one a partcular ELF object refers to.
It is possible that the same process may also use tcsetattr#GLIBC_2.42 at the same time, such as if it uses another dynamic library which was linked against a libc.so new enough to provide it. The version tags ensure that both the old binary and the new library get the function they expect from the C library.
Most libraries don't use this mechanism and instead just rename the entire library if they need to make breaking changes to their binary interfaces. For example, if you dump /usr/bin/pngtopnm you'll find that the symbols it imports from libnetpbm and libpng are not versioned. (Or at least that's what I see on my machine).
The cost of this is that you can't have a binary that links against one version of libpng and also links against another library that itself links against a different libpng version; the exported names from the two libpng's would clash.
In most cases this is manageable enough through careful packaging practice that maintaining the library source to produce useful version tags and stay backwards compatible is not worth the trouble.
But in the particular case of the C library and a few other vital system libraries, changing the name of the library would be so extremely painful that it makes sense for the maintainers to jump through some hoops in order to ensure it will never need to happen again.
Although in most cases every symbol is unique, there are a handful of exceptions. My favorite is multiple identical symbol import used by PAM (pluggable authentication modules) and NSS (Name Service Switch). In both cases all modules written for either interface use a standard interface with standard names. A common and frequently used example is what happens when you call get host by name. The nss library will call the same function in multiple libraries to get an answer. A common configuration calles the same function in three libraries! I have seen the same function called in five different libraries from one function call, and that was not the limit just what was useful. There is special calls to the dynamic linker need to do this and I have not familiarised myself with the mechanics of doing this, but there is nothing special about the linking of the library module that is so loaded.
Could anyone please tell me is this the right model for non-deterministic values of integer and unsigned integer in Frama-C?
/* Suppose Frama-C is installed in /usr/local -default prefix */
#include "/usr/local/share/frama-c/builtin.h"
#include "/usr/local/share/frama-c/libc/limits.h"
...
#define nondet_int() Frama_C_interval(INT_MIN, INT_MAX)
#define nondet_uint() Frama_C_interval(0, UINT_MAX)
...
Are there any exceptions if I use the above code with different architectures in option -machdep?
No, in the Neon version you have to manually define the appropriate macro if you want to use another -machdep. You would typically end up with a command-line like that:
frama-c -cpp-extra-args="-D__FC_MACHDEP_X86_64" -machdep x86_64
Forthcoming Sodium release will make the -cpp-extra-args unnecessary, as well as providing by default a -I option to let preprocessor search into Frama-C's libc header, so that you won't have to provide it yourself or rely on absolute paths in your #include directive
NB: This answer is not a commitment to any particular date for the Sodium release.
One reason Frama_C_interval(0, UINT_MAX) may not work as intended is that Frama_C_interval has type int (int, int). When you happen to want the entire range of unsigned int values, that actually tends to help because the conversions that are introduced are subject to approximation, but in general the fact that Frama_C_interval is declared as returning an int is a nuisance.
The latest released version already has Frama_C_unsigned_int_interval, but it is in share/libc/__fc_builtin.h (installed to /usr/local/share/frama-c/libc/__fc_builtin.h. The file builtin.h looks like a vestigial remnant, especially with the $Id$ line dating back to when development was done under SVN.
For specifying that a value should be all possible unsigned intvalues, Frama_C_unsigned_int_interval(0, -1) saves yourself the trouble of including limit.h. The int value -1 passed as argument is converted to the largest unsigned int as per C rules.
I got this error below and I can not find a solution. Does anybody know how
to fix this error?
rafael#ubuntu:~/avr/projeto$ clang -fsyntax-only -Os -I /usr/lib/avr/include -D__AVR_ATmega328P__ -DARDUINO=100 -Wno-ignored-attributes -Wno-attributes serial_tree.c
In file included from serial_tree.c:3:
In file included from /usr/lib/avr/include/util/delay.h:43:
/usr/lib/avr/include/util/delay_basic.h:108:5: error: invalid output
constraint
'=w' in asm
: "=w" (__count)
^
1 error generated.
util/delay.h is a Header from avr-libc, and the feature which you are using (some of the delay stuff) is using inline asm to implement it. avr-libc is written to be used with avr-gcc and uses features from avr-gcc like machine dependent constrains in inline asm. llvm does not recognize constraint "w", thus you have to use a different approach like using avr-gcc or porting that code to llvm.
avr-gcc also implements built-in function __builtin_avr_delay_cycles to implement wasting a specified number of clock cycles. If llvm is properly mimicking avr-gcc, then you can use that function as a starting point.
There are a few differences noticed in symbols between two binaries built using same sources on two AIX systems. One example for 'main':
xxxx1: .main T 4294975624
xxxx2: .main T 4294969472 516
xxxx2: main:F-1 - 0
Why the difference in sizes?
'T' is Global text symbol as per man page. What is 'F'?
Also, the sizes of two binaries vary significantly: 3924048 vs. 17701460. Why?
AIX versions, compiler versions, makefiles (same CFLAGS) are identical.
I'm fairly sure the F-1 is a function returning int. It is a "stab" string which is output when the compiler given the -g option. That would also be the reason for the size differences.
Can you try doing "size " and "size ". size also has an option to make it more verbose. You can also do "file " etc and it will tell you if it is stripped or not.
Between the -g and the strip flag at link time, I think that will account for the differences you are seeing.
HTH