[llvm-dev] Generating function definition for function that's only called during unwinding
Keith Wyss via llvm-dev
llvm-dev at lists.llvm.org
Tue May 1 20:34:42 PDT 2018
Hi,
I'm trying to understand how clang keeps track of which declarations are
called within a translation unit and decides to codegen their definitions.
DeclBase.h has a markUsed to keep track of ODR use, and I think that the
decl can be found from the symbol table via ASTContext.h (for example
looking up a template via GetQualifiedTemplateName -> getAsTemplateDecl ->
setIsUsed ). This is just a result of fumbling around in the dark, I could
be totally wrong.
I'd like to know what part of the system is responsible for tracking usage,
and whether that's the same mechanism that decides whether to CodeGen basic
blocks with function definitions.
Particularly, I'm curious about how the decision should be made whether to
emit a definition for a destructor that it is only called in a cleanup
block that's only invoked during unwinding. I don't actually understand how
or whether the control flow for unwinding is expressed in the AST at all. I
can't see anything related to unwinding control flow with -ast-dump for
instance.
I've been spending some time debugging a particular test program at bug
33778 <https://bugs.llvm.org/show_bug.cgi?id=33778> that fails to link
because a block only referenced from an LSDA contains a call instruction to
a destructor that has no generated definition. I'm hitting a wall because
I'm pretty ignorant of the structure of the codebase and any guidance would
be appreciated.
Any general guidance or documentation to help find my way around clang
would be awesome too.
Thanks,
Keith
P.S. The program that doesn't link without -fno-exceptions:
#include <functional>
struct X {
std::function<int()> F;
std::function<int()> G;
};
void foo(const std::function<int()>& a) {
new X{a, a};
}
int main() {
return 0;
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180501/09b2526e/attachment.html>
More information about the llvm-dev
mailing list