The Situation
We have a board with a TI DM3730 processor (also known from the Beagleboard) with a Cortex A8 core (r3p2) in use with the following parameters:
Beagleboard Reference Design: Beagleboard-xM Rev-C
Kernel version: 3.2.8
Open CV library: 2.4.6
U-Boot: uboot-2013.04
Toolchain: Sourcery CodeBench ARM 2011.03
Buildroot: 2012.02
The setup is derived from this blog
Now we have written a program (written in C++ and compiled with GCC Version 4.5.2.) which uses the OpenCV library (to calculate some scores using support vector machines) and which behaves in some strange way:
The program runs on the board in its own process using defined test data: It produces repeatedly correct results.
The program runs in two or more processes (with the same defined test data): The results start to become wrong for each process, processes die with segfaults. The last remaining process runs correctly again.
The program runs in its own process (with the same defined test data again). Additionally, another process changes some exposure settings of an attached camera: The program starts to produce wrong results.
So we assume this is a very low level floating point problem.
What we tried
The complete system (all libraries, kernel, boot loader, etc.) have been compiled with compiler flags as suggested on the pandorawiki.org regarding Floating_Point_Optimization
-O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp
-ffast-math -fsingle-precision-constant
We tried to enable L1NEON in Cortex-A8 aux ctrl register according to the Beagle board FAQ and tried the other options mentioned there as well, but unfortunately to no avail.
All three different behaviors are reproducible, but not in the form of a minimal working example.
The same program source and the first and second scenario run correctly on Windows (using Visual Studio) and on a desktop running Linux (GCC), so it's probably not something our code does.
So the questions are now:
Are there any other known bugs with this setup and floating point operations which we are not aware of?
Are there any known compiler options which should be set or omitted which can lead to the observed results?
If a MWE would be helpful, we will look into providing one.
Any clues are welcome.
Ok, we now use an up-to-date buildroot (2014.08) with the included toolchain (arm-buildroot-linux-uclibcgueabi-), Linux-kernel 3.9.11, boost 1.55, Qt 4.8.6, and still OpenCV 2.4.6.
When compiling, we optimize for size (–Os) and for target-optimization we only use –pipe.
The following compiler-flags are currently not used anymore:
-mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant
Unfortunately, we still don't know the exact reason for the original problem, but we are quite happy that the problem went away with this setup.
So maybe this answer helps some poor soul in the future... ;)
Related
How can I validate a newly created instruction using LLVM?
I am new to LLVM and computer architecture.
Created a new instruction of bfloat16 type arithmetic targeting the RISCV-32 architecture.
I was wondering if the output of this arithmetic instruction was correct. And I wanted to verify that the value stored in the float register is in IEEE754 bfloat16 format.
clang-14 -c -g -v --target=riscv32-unknown-elf -march=rv32izfh0p1 -menable-experimental-extensions -I/usr/include -o main.o main.c
riscv32-unknown-elf-gcc -g -o main main.o
I compiled it through the above command, and it was confirmed that the assembly code came out well as shown below.
enter image description here
Then, I tried to run compiled executable file with qemu-riscv32 and debug it using gdb. But an error illegal instruction occurred.
enter image description here
Question
I think an illegal instruction error occurred because QEMU and gdb don't have information about the new instruction I created. Other than modifying QEMU and GDB, is there any way to validate the newly created instruction?
If you extend a CPU architecture by adding new instructions to it, you need to add support for those in not just the toolchain (which will then output code using that new instruction) but also in the CPU implementation itself (so that it can execute the code your compiler now generates). You can do that either on a real hardware CPU, which in practice will start with changes to its RTL which can be tested in simulation; or you can do it on an emulated version of the CPU such as that which QEMU provides. But if you don't have an implementation of a CPU at all that has your new instructions in it, there's no point in having the compiler emit them, because you have nothing that can run the code that compiler produces.
I am trying to compile a code with crayftn.
I get an error message
/opt/cray/pe/cce/10.0.1/binutils/x86_64/x86_64-pc-linux-gnu/bin/ld: failed to convert GOTPCREL relocation; relink with --no-relax
So it wants the flag --no-relax? OK, I can do that. So I re-link with that flag, and then it tells me
ftn -O3 --no-relax -dynamic -h pic -h omp -o stream_cray stream_mpi.o mysecond.o
ftn-2115 crayftn: ERROR in command line
"-no-relax" is an invalid command-line option.
So it asks for "--no-relax", but then it doesn't understand it. Anyone know of a way out of this conundrum? Or another way of solving the root problem in the first place?
I found this link:
https://bb.cgd.ucar.edu/cesm/threads/failed-to-convert-gotpcrel-relocation-relink-with-no-relax.4494/
PROBLEM:
Hi, I get the following error message for CLM5.0 compilation with
Intel compilers, during the final cesm bld ..ld: failed to convert GOTPCREL relocation; relink with --no-relax
SOLUTION:
Hi, Seems like found a solution to fix the compilation ...Adding of
"-Wl,--no-relax" in LDFLAGS does not solve this problem, but
"-mcmodel medium" in FFLAGS fixes this issue, after searching for
"Relocation truncated to fit" in google search engine, it comes up
with this link which was helpful to solve the issue
"https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/268394"
Best Regards,Prabhakar
See also:
https://community.intel.com/t5/Intel-Fortran-Compiler/relocation-truncated-to-fit/td-p/1146616
This looks like mixing compilers and libraries from different systems
mixed up, either 32bit vs. 64bit or installations for ifort and
mpiifort based on different glibc or something similar.
I'm still curious about your "development environment":
Q: Have you been able to successfully compile, link and run ANY
program with your crayftn? Q: What version of crayftn? 10.0.1? Q: What
platform? Where is x86_64-pc-linux coming from? Just curious...
I am trying to run the Woden Physics Example inside Pharo which involves getting Bullet properly compiled and the smalltalk bindings properly installed in Pharo.
I am using Linux Mint 17 x64.
But NativeBoost seems unable to load the compiled libraries. I have been using the sources provided here:
https://github.com/ronsaldo/bullet-pharo
https://github.com/ronsaldo/swig
I built the modified version of swig as well as the bullet libraries and bindings with the provided build scripts.
I also have doublechecked that the bullet libraries are 32 bit.
Opening up the Woden physics example returns this error:
failed to get a symbol address:
PharoNB_new_BTDefaultCollisionConfiguration__SWIG_1
When examining the call stack in the debugger, it turns out that the module handle is 0.
I verified this by executing the same message as
BulletCInterface nbLibraryNameOrHandle
executes:
NativeBoost forCurrentPlatform loadModule: 'BulletPharo'
This message returns 0. I tried to specify the full path to libPharoBullet.so in the workspace, like:
NativeBoost forCurrentPlatform loadModule:
'/home/martin/.local/share/Pharo/bullet-pharo/libBulletPharo.so'
with the same result. I also verified it with a 32 bit system library of mine (liblzma) and there NativeBoost was able to load it, as it returned a non-zero handle.
So i suspect something during compilation went wrong...
I also did
readelf -h libPharoBullet.so
and its ABI was "UNIX - GNU" while the ABI of pharo-vm is "UNIX - System V"
Could this be the problem here ?
How can i force the ABI to be System V when compiling ? I use gcc 4.8.2
Or what steps could i otherwise perform ?
I'm running Clang 3.4 on Ubuntu 12.10 (from http://llvm.org/apt/). I ran the analyzer (clang --analyze) over some code, and it found a couple of issues:
Blah.C:429:9: warning: Declared variable-length array (VLA) has zero size
unsigned char separatedData[groupDataLength];
^~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~
But the specific issue isn't important. I want to know the steps of how it came to that conclusion (the code is complex enough for me not to see it within 15 mins).
I see a screenshot from the Clang site that shows steps of working viewed in a web browser:
That's probably obtained from Xcode.
The question is: how do I get Clang to output such steps of working from the command line? Or even output results to a browser if it so wishes? This would make the analyzer significantly more useful, and make fixing things much quicker.
(I have noticed that GCC's documentation is very excellent, but Clang/LLVM's documentation is very poor. I've tried "clang --analyze -Xanalyzer '-v'" as a stab in the dark to tell the analyzer to be more verbose -- the -Xanalyzer switch was from the man pages.)
In addition to text output on the console:
clang++ --analyze -Xanalyzer -analyzer-output=text main.cpp
You can get the full html output:
clang++ --analyze -Xanalyzer -analyzer-output=html -o html-dir main.cpp
Additionally, you can select specific checkers to enable. This page lists available checks. For example, you can enable all of the C++ checks in the alpha group using the flags:
-Xanalyzer -analyzer-checker=alpha.cplusplus
http://coliru.stacked-crooked.com/a/7746c4004704d4a7
main.cpp:5:1: warning: Potential leak of memory pointed to by 'x'
}
^
main.cpp:4:12: note: Memory is allocated
int *x = new int;
^~~~~~~
main.cpp:5:1: note: Potential leak of memory pointed to by 'x'
}
^
Apparently the front end exposes
-analyzer-config <Option Name>=<Value>
E.g.
-analyzer-config -analyzer-checker=alpha.cplusplus
which might be better supported than -Xanalyzer and may be getting extended to support options to individual checkers: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-October/039552.html
You are on the right track, but to get the full trace leading to a bug you additionally need to ask clang for output in text format (don't ask why). Since you will probably need to adjust e.g. include paths or defines for your project anyway I'd suggest you use clang-check which acts as a wrapper around clang's analyzer pass. It can also hook into the static analyzer tools exposed in e.g. scan-build. You can then
$ clang-check -analyze -extra-arg -Xclang -extra-arg -analyzer-output=text
Like you wrote the documentation for these very nice tools is abysmal. I cobbled above call together from bits and pieces from Chandler Carruth's GoingNative2013 talk.
You have to use scanbuild: http://clang-analyzer.llvm.org/scan-build.html
You type the commands that generate your build, but you pre-pend them with scan-build.
Example:
instead of
make
type
scan-build make
instead of
./configure
make
type
scan-build ./configure
scan-build make
Clear the build before launching the analyzer, otherwise make will state that everything has been built already and the analyzer will not run.
I have a C++ project that was built and runs in Visual Studio.
When I try to run it in unix, it gives me
Abort (Core Dumped)
I am using the g++ version 3.2.2
How do i Fix this program ? It needs to run in linux.
First step is to learn how to use gdb or any of the other excellent debuggers for Linux.
That should be able to tell you exactly which source line caused the problem. Then work back from there.
Other than that, we can't really help without seeing that source code. Psychic debugging, whilst useful, is not a highly developed field of endeavour :-)
#All
Thanks a lot for your responses.I really appreciate it
My program worked with g++ 4.2.3. It was aborting with g++ 3.2.2.
The code that gave me the correct output in visual studio was
foundOpen = inStr.find("(");
foundClose = inStr.find(")");
string inGate;
inGate = inStr.substr(++foundOpen,foundClose-foundOpen);
But using g++, I had to make a small change to the substr function.
foundOpen = inStr.find("(");
foundClose = inStr.find(")");
string inGate;
inGate = inStr.substr(++foundOpen,foundClose-foundOpen-1);
I am also a beginner to using linux and don't know how to use gdb. Are there any good tutorials to learn gdb?
I'll take a flying guess: your program uses 'getch()' and you found the function in the library -lcurses or -lncurses and are using that library, but your program crashes as you said.
The trouble is, that function requires a certain amount of setup to work - unlike the similarly named but rather different function that is available on Windows.
Welcome to the real world - different platforms have different functions in the standard APIs; sometimes, two platforms have a function with the same name but different meanings.
Another wild guess: boolean initialization, we got bit by this one. The boolean was initialized automatically using VC++2003 but on Linux it was not (thus either true or false, flip a coin...).
Took a while to debug since in our case it did not crash and was intermittent. I wanted to slap the programmer on the head for not initializing his variable!