LLVM ERROR: Program used external function '??_7type_info@@6B@' which could not be resolved!

Clang Frontend
#1

Hi,

When I try to run this code via lli:

#include <stdio.h>

int main()
{
    try
    {
        throw "hi";
    }
    catch (const char *msg)
    {
        printf("%s\n", msg);
    }
    return 0;
}

It works as expected on linux but fails on windows:
LLVM ERROR: Program used external function '??_7type_info@@6B@' which could not be resolved!

This is what I execute:
  clang -fexceptions -c -emit-llvm a.cpp
  lli a.bc

I guess "??_7type_info@@6B@" (aka "const type_info::`vftable'") comes from libcmt.lib and would require link.exe to resolve.
type_info sounds like RTTI, but disabling (-fno-rtti) doesn't it fix the problem, I guess it's a requirement for exceptionhandling?

Is there a way to use gnu exception handling on windows generated bitcode? For my usecase, its perfectly fine to break compatibility to microsoft binaries (I tried to run clang with various targettriples, but didn't get it to work)

#2

Hi,

When I try to run this code via lli:

#include <stdio.h>

int main()
{
     try
     {
         throw "hi";
     }
     catch (const char *msg)
     {
         printf("%s\n", msg);
     }
     return 0;
}

It works as expected on linux but fails on windows:
LLVM ERROR: Program used external function '??_7type_info@@6B@' which could not be resolved!

This is what I execute:
  clang -fexceptions -c -emit-llvm a.cpp
  lli a.bc

I guess "??_7type_info@@6B@" (aka "const type_info::`vftable'") comes from libcmt.lib and would require link.exe to resolve.
type_info sounds like RTTI, but disabling (-fno-rtti) doesn't it fix the problem, I guess it's a requirement for exceptionhandling?

Did you build llvm itself with rtti, and exceptions?

#3

Hi,

When I try to run this code via lli:

#include <stdio.h>

int main()
{
    try
    {
        throw "hi";
    }
    catch (const char *msg)
    {
        printf("%s\n", msg);
    }
    return 0;
}

It works as expected on linux but fails on windows:
LLVM ERROR: Program used external function '??_7type_info@@6B@' which
could not be resolved!

This is what I execute:
        clang -fexceptions -c -emit-llvm a.cpp
        lli a.bc

I guess "??_7type_info@@6B@" (aka "const type_info::`vftable'") comes
from libcmt.lib and would require link.exe to resolve.
type_info sounds like RTTI, but disabling (-fno-rtti) doesn't it fix the
problem, I guess it's a requirement for exceptionhandling?

Exception handling relies on RTTI and controls different, but related,
machinery from -fno-rtti.

Is there a way to use gnu exception handling on windows generated bitcode?

Yes, you could use a mingw triple.

#4

> I guess "??_7type_info@@6B@" (aka "const type_info::`vftable'") comes
from libcmt.lib and would require link.exe to resolve.
> type_info sounds like RTTI, but disabling (-fno-rtti) doesn't it fix the
problem, I guess it's a requirement for exceptionhandling?

Did you build llvm itself with rtti, and exceptions?

I made a scratchmake with enabled LLVM_ENABLE_EH and LLVM_ENABLE_RTTI, but the error is still the same.
(I also had to add /EHsc and /bigobj to CMAKE_CXX_FLAGS_DEBUG to make msvc happy)

C:\clang>build\Debug\bin\clang --version
clang version 3.8.1 (https://github.com/llvm-mirror/clang.git 2cb088be9c6a3d1ef9a050d44e1b01393983fc4d) (https://github.com/llvm-mirror/llvm.git 051e787f26dbfdc26cf61a57bc82ca00dcb812e8)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\clang\build\Debug\bin

With "-cc1", I can now also force clang to generate gnu exceptionhandling, but this introduces lots of _cxa dependencies, which would also be problem.

I played around with SJLJ EH. I know its not exactly zero cost, but it would still solve a lot of problems. Unfortunately, enabling it (-fsjlj-exceptions) hits an assert in codegen:
Assertion failed: handler.Type.Flags == 0 && "landingpads do not support catch handler flags", file C:\clang\src\tools\clang\lib\CodeGen\CGException.cpp, line 814

Would SJLJ require library support too?

Are there plans to get exceptionhandling on windows, without link.exe, to work?

Thx.

#5

There are no plans to support EH without either the MSVC or GNU standard
C++ library. If you can convince lli to resolve symbols against either one
of those, you should be in business.