yonghong-song added a comment.
I found an easy way to reproduce the issue and also did some preliminary
analysis. I have filed a bug https://bugs.llvm.org/show_bug.cgi?id=40170. The
reproducible case and my analysis is below:
-bash-4.4$ cat ttest2.c
#include "ttest.h"
BPF_PERF_OUTPUT2(probe);
int main() { return g; }
-bash-4.4$ cat ttest.h
#define BPF_PERF_OUTPUT2(_name) \
struct _name##_table_t { \
int key; \
unsigned leaf; \
int (*perf_submit) (void *, void *, unsigned); \
int (*perf_submit_skb) (void *, unsigned, void *, unsigned); \
unsigned max_entries; \
}; \
__attribute__((section("maps/perf_output"))) \
struct _name##_table_t _name = { .max_entries = 0 }
int g;
-bash-4.4$ clang -g -O2 -gdwarf-5 -gembed-source -c ttest2.c
inconsistent use of embedded source
fatal error: error in backend: Broken module found, compilation aborted!
clang-8: error: clang frontend command failed with exit code 70 (use -v to see
invocation)
clang version 8.0.0 (trunk 350092) (llvm/trunk 350084)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/yhs/work/llvm/build/install/bin
clang-8: note: diagnostic msg: PLEASE submit a bug report to
https://bugs.llvm.org/ and include the crash backtrace, preprocessed source,
and associated run script.
clang-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-8: note: diagnostic msg: /tmp/ttest2-6c497a.c
clang-8: note: diagnostic msg: /tmp/ttest2-6c497a.sh
clang-8: note: diagnostic msg:
********************
-bash-4.4$
Basically, a simple C file and header file. The C file contains a macro
expansion. Compiling with -g -gdwarf-5 -gembed-source will cause the
compiler complains:
fatal error: error in backend: Broken module found, compilation aborted!
When I tried to root cause the bug described in
https://reviews.llvm.org/D53329, I found a simple test case like the above will
break clang.
I did some analysis. The following are rough reason.
1. Looks like for macro in the source code, the clang actually will create a
"FileID" for it. The FileID is not associated with a file. It is actually
associated with a source location range.
2. In my particular example, the macro defines a global variable and the global
variable needs a file.
3. When clang tries to find the FileID based on source location of the global
variable, it found a source expansion FileID which does not have source
associated with it.
4. So clang simply does not have a "source" attribute for the DIFile
corresponding to the global as in (3) it does not have such information.
5. Later on, IR verification complains embed-source is enabled but all not
DIFile has sources, so aborted.
My above workaround is obviously incorrect. But I am not sure what is the
correct way to fix this issue. Maybe one of you can help. Thanks!
Repository:
rC Clang
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D53329/new/
https://reviews.llvm.org/D53329
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
