Is exception Handling support provided for Arm Architecture as per now by LLVM.
I am using CLANG++ with LLVM (version 3.0) and generating Arm binaries. But there is a problem with exception handling that whenever the code throws an exception , the code terminates with error " terminate after throwing an exception ".\
You have not specified the platform... EH should fully be supported on arm/darwin. The stuff on arm/linux is not so good, it's work in progress there.
Related
I have this C++ code that asserts atomic bools are always lock-free (for reference, this is from Godot Engine):
static_assert(std::atomic_bool::is_always_lock_free);
This works fine on x86, but when compiling with GCC for RISC-V, this assert fails with this message:
./core/templates/safe_refcount.h:140:34: error: static assertion failed
140 | static_assert(std::atomic_bool::is_always_lock_free);
| ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
This assert doesn't fail when compiling with Clang (clang++), it only happens with GCC (g++).
I've been looking around for awhile but the available resources for RISC-V are fairly low. I did find this somewhat similar question about lock-free atomics on ARM on a Raspberry Pi 3 where the problem is that the compiler is unaware that atomic bools are guaranteed to be lock-free at compile time. If this is the case, perhaps I am just missing some compiler flag. Alternatively, it is possible that the target architecture is missing a RISC-V extension for this (I have tried both the default rv64imafdc, and rv64gc), but I doubt it since the same target works with Clang.
I have a C++ GUI project built for 32-bit MinGW 7.30 using Qt Creator 4.9.2 for Qt 5.12.4. When I run my project from Qt Creator in debug mode (in Windows 10), I am getting error messages from deep in the bowels of the QTreeView code, of the form
HEAP: Free Heap block 2E185810 modified at 2E185858 after it was freed
This means that Qt is running heap diagnostics. But I can't find out how to access these diagnostics programatically, to find the source of the problem. (I am assuming that the fault lies with my code and not with Qt, although this is obviously not 100% guaranteed.) The Windows diagnostic tools such as _CrtMemoryCheck are #defined out in the MinGW header files.
Does anybody know why these diagnostics are not available for MingW? Is it possible that they simply don't work, that Qt is running them anyway, and the error messages are spurious? If the errors are genuine, is there any way to find out more about them?
For debugging sporadic crashes in Sophis Risque, we need to be able to run Sophis with our C++ plugins in a run-time code analysis tool such as BoundsChecker or Purify. I have successfully used both of these tools Risque 4.x versions, but none of them works anymore since Risque 5.3.x. Even without our plugins, neither the Sophis Client, nor any Toolkit API applications ever manage to successfully initialize the session - the process will crash before the Toolkit Log is created. I have the impression that Risque stopped working with Purify somewhere between risque 4.5 and 5.2, and with BoundsChecker between risque 5.2 and 5.3. Under Risque 5.3, I've tried upgrading BoundsChecker from 9.01 to 10.5.897.1, but the same problem occurred: during the call to CSRApi::Initialise() an "Unhandled exception" was detected and the process couldn't continue. Meanwhile we use Risque 6.3.x and need some serious tools for debugging.
Question: Which run-time memory checking tools (and which versions thereof) have been ever known to work with Sophis Risque 6.x ? Are we really limited to the Basic Runtime Checks available for debug builds in Visual Studio via C++ project properties->Code Generation->Basic Runtime Checks (/RTCs /RTCu /RTCsu)? Thanks!
Few days ago, I have found out the oracle instant client is not compatible with LLVM C++ library due to EXC_BAD_ACCESS. Therefore, I change the library to GNU C++ library and every thing works.
Today, I realized the error from oracle client may be caused by returning a local variable. When the program is compiled with LLVM C++ library, EXC_BAD_ACCESS comes out. However, I change the library to GNU C++ library, the vector can push 10 but it cannot get back the 10. I have no idea why EXC_BAD_ACCESS only occurs with LLVM library.
LLVM (local)
GNU(local)
You are invoking undefined behaviour.
Exactly what happens on any given execution of your program is not defined and can vary from compiler to compiler. That is clearly what is happening here. You just got unlucky that that your broken code ran without error with the GNU library.
I can't find enough information to decide which compiler should I use to compile my project. There are several programs on different computers simulating a process. On Linux, I'm using GCC. Everything is great. I can optimize code, it compiles fast and uses not-so-much memory.
I do my own benchmark with MSVC and GCC compilers. Later one produces slightly faster binaries (for each subarchitecture). Though compile time is much more than MSVC.
So I decided to use MinGW. But can't find any explanation about exception handling methods and their implementations in MinGW. I can use different distributions for different operating systems and architectures.
Considerations:
Compile time and memory are not important for my usage. Only important thing is runtime optimization. I need my programs to be fast enough. A slow compiler is acceptable.
OS: Microsoft Windows XP / 7 / 8 / Linux
Architecture: Intel Core i7 / Core2 / and a very old i686 running XP :P
There's a short overview at MinGW-w64 Wiki:
Why doesn't mingw-w64 gcc support Dwarf-2 Exception Handling?
The Dwarf-2 EH implementation for Windows is not designed at all to
work under 64-bit Windows applications. In win32 mode, the exception
unwind handler cannot propagate through non-dw2 aware code, this means
that any exception going through any non-dw2 aware "foreign frames"
code will fail, including Windows system DLLs and DLLs built with
Visual Studio. Dwarf-2 unwinding code in gcc inspects the x86
unwinding assembly and is unable to proceed without other dwarf-2
unwind information.
The SetJump LongJump method of exception handling works for most
cases on both win32 and win64, except for general protection faults.
Structured exception handling support in gcc is being developed to
overcome the weaknesses of dw2 and sjlj. On win64, the
unwind-information are placed in xdata-section and there is the .pdata
(function descriptor table) instead of the stack. For win32, the chain
of handlers are on stack and need to be saved/restored by real
executed code.
GCC GNU about Exception Handling:
GCC supports two methods for exception handling (EH):
DWARF-2 (DW2) EH, which requires the use of DWARF-2 (or DWARF-3) debugging information. DW-2 EH can cause executables to be
slightly bloated because large call stack unwinding tables have to be
included in th executables.
A method based on setjmp/longjmp (SJLJ). SJLJ-based EH is much slower than DW2 EH (penalising even normal execution when no
exceptions are thrown), but can work across code that has not been
compiled with GCC or that does not have call-stack unwinding
information.
[...]
Structured Exception Handling (SEH)
Windows uses its own exception handling mechanism known as Structured Exception Handling (SEH). [...]
Unfortunately, GCC does not support SEH yet. [...]
See also:
Exception handling models of GCC
C++ Exception Handling for IA-64
EH newbies howto
SJLJ (setjmp/longjmp): – available for 32 bit and 64 bit – not “zero-cost”: even if an exception isn’t thrown, it incurs a minor
performance penalty (~15% in exception heavy code) – allows exceptions
to traverse through e.g. windows callbacks
DWARF (DW2, dwarf-2) – available for 32 bit only – no permanent runtime overhead – needs whole call stack to be dwarf-enabled, which
means exceptions cannot be thrown over e.g. Windows system DLLs.
SEH (zero overhead exception) – will be available for 64-bit GCC 4.8.
source: https://wiki.qt.io/MinGW-64-bit