cxa_thread_atexit_test crashes in backend
brooksdavis opened this issue · 2 comments
brooksdavis commented
https://gist.github.com/brooksdavis/d4ba7b5d9f64134268ba138bec70f397
fatal error: error in backend: Cannot select: 0x80942a000: iFATPTR128 =
GlobalTLSAddress<i64 addrspace(200)* @_ZGVZN3BarD1EvE3foo> 0
In function: _ZN3BarD2Ev
clang-3.8: error: clang frontend command failed with exit code 70 (use -v to se$ invocation)
clang version 7.0.0 (https://github.com/llvm-mirror/clang.git 64f619a5b1a4830b4$1276f96a56ff1e5c845623) (https://github.com/llvm-mirror/llvm.git 4d53edbfeab4ae$6580c339b9279214cdfae9208)
Target: cheri-unknown-freebsd
Thread model: posix
InstalledDir: /home/bed22/git/llvm-cheri/Build/bin
clang-3.8: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/$ugs/ and include the crash backtrace, preprocessed source, and associated run s$ript.
clang-3.8: note: diagnostic msg:
********************
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-3.8: note: diagnostic msg: /tmp/cxa_thread_atexit_test-84949b.cpp
clang-3.8: note: diagnostic msg: /tmp/cxa_thread_atexit_test-84949b.sh
clang-3.8: note: diagnostic msg:
arichardson commented
creduce_crash_testcase output:
// RUN: %cheri_purecap_cc1 -fuse-init-array -mllvm -cheri-cap-table=false -O2 -std=c++11 -fdeprecated-macro -fcxx-exceptions -fexceptions -fcolor-diagnostics -vectorize-loops -vectorize-slp -mllvm -cheri-cap-table-abi=pcrel -o - -S %s
template <class a, class = a, class = a> class b;
class c {
public:
long d;
c();
};
class e {};
class g {
public:
g(e *);
};
template <class> class i : public e {
public:
i();
};
template <class j> i<j>::i() { c(); }
template <class, class, class> class b : g {
i<int> k;
public:
b();
};
template <class a, class l, class j> b<a, l, j>::b() : g(&k) {}
struct m {};
struct n {
n() {
b<char> o;
c p;
}
};
thread_local m f;
thread_local n h;
class q {
void r() const;
};
void q::r() const { f; }
arichardson commented
This is caused by clang putting __tls_guard in AS200. Eventually we should be doing that but for now LLVM just doesn't know how to handle TLS variables in AS200. Once we set caphwr 1 in the kernel we could start using that to generate TLS accesses.