[PATCH] D53329: Generate DIFile with main program if source is not available

[Yonghong Song via Phabricator via cfe-commits]

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