Thread (11 messages) 11 messages, 4 authors, 2021-03-31

Re: [PATCH kbuild] kbuild: add -grecord-gcc-switches to clang build

From: Fāng-ruì Sòng <hidden>
Date: 2021-03-31 02:40:52
Also in: linux-kbuild

On Tue, Mar 30, 2021 at 6:48 PM Yonghong Song [off-list ref] wrote:


On 3/30/21 5:25 PM, Fangrui Song wrote:
quoted
On 2021-03-30, 'Yonghong Song' via Clang Built Linux wrote:
quoted

On 3/29/21 3:52 PM, Nick Desaulniers wrote:
quoted
(replying to
https://lore.kernel.org/bpf/20210328064121.2062927-1-yhs@fb.com/ (local))

Thanks for the patch!
quoted
+# gcc emits compilation flags in dwarf DW_AT_producer by default
+# while clang needs explicit flag. Add this flag explicitly.
+ifdef CONFIG_CC_IS_CLANG
+DEBUG_CFLAGS    += -grecord-gcc-switches
+endif
+
Yes, gcc defaults to -grecord-gcc-switches. Clang doesn't.
Could you know why? dwarf size concern?
quoted
quoted
quoted
This adds ~5MB/1% to vmlinux of an x86_64 defconfig built with clang.
Do we
want to add additional guards for CONFIG_DEBUG_INFO_BTF, so that we
don't have
to pay that cost if that config is not set?
Since this patch is mostly motivated to detect whether the kernel is
built with clang lto or not. Let me add the flag only if lto is
enabled. My measurement shows 0.5% increase to thinlto-vmlinux.
The smaller percentage is due to larger .debug_info section
(almost double) for thinlto vs. no lto.

ifdef CONFIG_LTO_CLANG
DEBUG_CFLAGS   += -grecord-gcc-switches
endif

This will make pahole with any clang built kernels, lto or non-lto.
I share the same concern about sizes. Can't pahole know it is clang LTO
via other means? If pahole just needs to know the one-bit information
(clang LTO vs not), having every compile option seems unnecessary....
This is v2 of the patch
   https://lore.kernel.org/bpf/20210331001623.2778934-1-yhs@fb.com/ (local)
The flag will be guarded with CONFIG_LTO_CLANG.

As mentioned in commit message of v2, the alternative is
to go through every cu to find out whether DW_FORM_ref_addr is used
or not. In other words, check every possible cross-cu references
to find whether cross-cu reference actually happens or not. This
is quite heavy for pahole...

What we really want to know is whether cross-cu reference happens
or not? If there is an easy way to get it, that will be great.
+David Blaikie
quoted
quoted
If the maintainer wants further restriction with CONFIG_DEBUG_INFO_BTF,
I can do that in another revision.

--
You received this message because you are subscribed to the Google
Groups "Clang Built Linux" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clang-built-linux+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/clang-built-linux/0b8d17be-e015-83c3-88d8-7c218cd01536@fb.com
.


-- 
宋方睿
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help