Putting compilation flags in dwarf is helpful in that
it tells what potential transformations may have
happened to generate the final binary. Furthermore,
we have a particular usecase in [1] where pahole wants
to detect whether vmlinux is compiled with clang lto
or not, and if vmlinux is compiled with clang lto,
pahole will merge all debuginfo cu's into one pahole cu.
If there is no easy indicator for whether the vmlinux
is compiled with lto or not, pahole will need to
go to each cu to iterates all die's to find out
whether there is a cross-cu reference, for example,
for one vmlinux I built locally with clang lto,
5 cu's need to be visited before finding there is
a cross-cu reference. To visit all cu's just proving
there is no cross-cu reference is a heavy penalty
for most pahole users whose codes may not be compiled
with lto.
One way to get whether vmlinux is built with lto or not
is through compilation flags. Currently gcc seems putting
compilation flags into dwarf DW_AT_producer tag if -g
is specified, while clang needs explicit flag
-grecord-gcc-switches.
For example,
build with gcc 8.4.1 (make -j60):
...
DW_AT_producer ("GNU C89 8.4.1 20200928 (Red Hat 8.4.1-1) -mno-sse -mno-mmx -mno-sse2 ...")
DW_AT_language (DW_LANG_C89)
DW_AT_name ("/home/yhs/work/bpf-next/arch/x86/kernel/ebda.c")
build with clang 13 trunk (make -j60 LLVM=1):
...
DW_AT_producer ("clang version 13.0.0 (https://github.com/llvm/llvm-project.git
11bf268864afbe35ad317e6354c51440d5184911)")
DW_AT_language (DW_LANG_C89)
DW_AT_name ("/home/yhs/work/bpf-next/arch/x86/kernel/ebda.c")
To solve out use case, the flag is added when clang lto
(thin-lto or full-lto) is enabled. With this patch, build
with clang 13 trunk (make -j60 LLVM=1 LLVM_IAS=1):
...
DW_AT_producer ("clang version 13.0.0 (https://github.com/llvm/llvm-project.git
11bf268864afbe35ad317e6354c51440d5184911)
/home/yhs/work/llvm-project/llvm/build.cur/install/bin/clang-13 -MMD
-MF arch/x86/kernel/.ebda.o.d -nostdinc ...")
DW_AT_language (DW_LANG_C89)
DW_AT_name ("/home/yhs/work/bpf-next/arch/x86/kernel/ebda.c")
pahole can just check top die of the dwarf cu to find the compilation flags.
With detailed compilation flags, in [1], pahole is able to quickly
decide whether merging cu's is a right choice or not.
[1] https://lore.kernel.org/bpf/20210325065316.3121287-1-yhs@xxxxxx/
I tested with latest bpf-next, but the patch is also applied cleanly on
top of latest linus tree.
Signed-off-by: Yonghong Song <yhs@xxxxxx>
---
Makefile | 8 ++++++++
1 file changed, 8 insertions(+)
Changelogs:
v1 -> v2:
. guard with CONFIG_LTO_CLANG instead of CONFIG_CC_IS_CLANG
diff --git a/Makefile b/Makefile
index d4784d181123..74001f2ccf23 100644
--- a/Makefile
+++ b/Makefile
@@ -839,6 +839,14 @@ dwarf-version-$(CONFIG_DEBUG_INFO_DWARF5) := 5
DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y)
endif
+# gcc emits compilation flags in dwarf DW_AT_producer by default
+# while clang needs explicit flag. Let us enable compilation
+# flags emission if compiled with clang lto which helps
+# application distinguish lto vs. non-lto build.
+ifdef CONFIG_LTO_CLANG
+DEBUG_CFLAGS += -grecord-gcc-switches
+endif
+
ifdef CONFIG_DEBUG_INFO_REDUCED
DEBUG_CFLAGS += $(call cc-option, -femit-struct-debug-baseonly) \
$(call cc-option,-fno-var-tracking)
--
2.30.2
