On Tue, Mar 30, 2021 at 7:39 PM Fāng-ruì Sòng <maskray@xxxxxxxxxx> wrote: > > On Tue, Mar 30, 2021 at 6:48 PM Yonghong Song <yhs@xxxxxx> wrote: > > > > > > > > On 3/30/21 5:25 PM, Fangrui Song wrote: > > > On 2021-03-30, 'Yonghong Song' via Clang Built Linux wrote: > > >> > > >> > > >> On 3/29/21 3:52 PM, Nick Desaulniers wrote: > > >>> (replying to > > >>> https://lore.kernel.org/bpf/20210328064121.2062927-1-yhs@xxxxxx/) > > >>> > > >>> Thanks for the patch! > > >>> > > >>>> +# 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? > > > > > > > >>> 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@xxxxxx/ > > 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 Yep, that shouldn't be too hard to test for more directly - scanning .debug_abbrev for DW_FORM_ref_addr should be what you need. Would that be workable rather than relying on detecting clang/lto from command line parameters? (GCC can produce these cross-CU references too, when using lto - so this approach would help make the solution generalize over GCC's behavior too)
