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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> >
> >> 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@xxxxxxxxxxxxxxxx.
> >> To view this discussion on the web visit
> >> https://groups.google.com/d/msgid/clang-built-linux/0b8d17be-e015-83c3-88d8-7c218cd01536@xxxxxx
> >> .



-- 
宋方睿




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux