[odb-users] Re: using ODB with cross-compiler x86_64-linux-gnu ->
ratkaisut at gmail.com
Sun Oct 23 16:19:12 EDT 2016
I have just realized the cause of SIGSEGV when the following lines of
codes are executed:
unique_ptr<odb::database> db(new odb::mssql::database("user",
"password", "", "testbench\\SQLEXPRESS2005"));
odb::transaction t(db->begin()); //<-------- SIGSEGV generated here
This is because exceptions normally occur in odbc32.dll, however, the
default exception ABI used in the cross-compiled binaries was for some
reason dwarf-2. not sjlj.
Here's the information concerning DW2:
"GCC currently supports two methods of stack frame unwinding: Dwarf-2
(DW2) or SJLJ (setjmp/longjmp). Until recently, only SJLJ has been
available for the Windows platform. This affects you, the end user,
primarily in programs that throw and catch exceptions. Programs which
utilize the DW2 unwind method generally execute more quickly than
programs which utilize the SJLJ method, because the DW2 method incurs
no runtime overhead until an exception is thrown. However, the DW2
method does incur a size penalty on code that must handle exceptions,
and more importantly the DW2 method cannot yet unwind (pass
exceptions) through "foreign" stack frames: stack frames compiled by
another non-DW2-enabled compiler, such as OS DLLs in a Windows
As you can realize, the vectored exception handler is unable to pass
the exception to the structured exception handler located in
odbc32.dll hence the totally innocent code was believed to have caused
memory access violation.
Do not use DW2 in mingw32 targets, cross-compiled or not!
On Mon, Oct 10, 2016 at 5:06 PM, Boris Kolpackov
<boris at codesynthesis.com> wrote:
> Hi Andrew,
> Andrew Cunningham <odb at a-cunningham.com> writes:
>> I am confused as to why you are trying to do this when the ODB compiler
>> and libraries are available on Windows.
> Some of us prefer not to leave the comfort of our Linux/Emacs and use
> cross-compilers for Windows ;-).
> What Sten is trying to do is use the GCC cross-compiler as the underlying
> compiler for ODB. This can become important if you include some Windows-
> specific stuff (e.g., <windows.h>) in headers that you compile with ODB;
> if you were to use a native (e.g., Linux-targeting) ODB build, then it
> won't be able to compile such headers.
More information about the odb-users