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

[Yonghong Song <yhs@fb.com>]

On 3/30/21 7:51 PM, David Blaikie wrote:
> On Tue, Mar 30, 2021 at 7:39 PM Fāng-ruì Sòng <maskray@google.com> wrote:
>>
>> On Tue, Mar 30, 2021 at 6:48 PM Yonghong Song <yhs@fb.com> 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@fb.com/)
>>>>>>
>>>>>> 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@fb.com/
>>> 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)

Thanks, David. This should be better. I tried with a non-lto vmlinux.
Did "llvm-dwarfdump --debug-abbrev vmlinux > log" and then
"grep "DW_CHILDREN_no" log | wc -l" and get 231676 records.

I will try this approach. If the time is a very small fraction of
actual dwarf cu processing time, we should be fine. This definitely 
better than visit all die's in cu trying to detect cross-cu reference.