Re: ppc64le vmlinuz is huge when building with BTF

[Alan Maguire <alan.maguire@oracle.com>]

On 15/06/2023 12:52, Dominique Martinet wrote:
> Jiri Olsa wrote on Thu, Jun 15, 2023 at 10:39:18AM +0200:
>>> coming from alpine: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12563
>>
>> it's probably burried somewhere in that discussion, but do you have
>> kernel version (or commit) where that increase happened?
> 
> Unfortunately not -- we've just tried on the 6.1.33 that's the current
> alpine lts kernel, but I cannot say since when this started because
> we've just enabled BTF recently.
> 
> Alpine also doesn't seem to keep old versions of apk files on its
> mirrors so while it probably has been happening since it got enabled I
> don't know how to check, and the commit enabling BTF has been done
> without a MR so there's no test log that'd allow seeing the package size
> either :/
> 
>> also link for used config would be great
> 
> alpine has two configs which both exhibit the issue (raw file link on
> commit before removing BTF):
> https://gitlab.alpinelinux.org/alpine/aports/-/raw/749ee7117e1437b7ab3ef2590f7f2e3558fda3ef/main/linux-lts/virt.ppc64le.config
> Size difference for linux-virt: 219 MiB -> 47 MiB
> https://gitlab.alpinelinux.org/alpine/aports/-/raw/749ee7117e1437b7ab3ef2590f7f2e3558fda3ef/main/linux-lts/lts.ppc64le.config
> Size difference for linux-lts: 306 MiB -> 74 MiB
>

I took a look (gunzip'ed and tar-extracted the apk to get the
vmlinuz-lts file) and the BTF looks reasonable size-wise:

$ objdump -h vmlinuz-lts
...

 13 .BTF          003d64cc  c000000001400844  0000000001400844  01410844
 2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 14 .BTF_ids      00000248  c0000000017d6d10  00000000017d6d10  017e6d10
 2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA

So BTF is ~4MB if I'm reading the above right.

However the problem I suspect is this:

 51 .debug_info   0a488b55  0000000000000000  0000000000000000  026f8d20
 2**0
                  CONTENTS, READONLY, DEBUGGING
 52 .debug_abbrev 004d66f0  0000000000000000  0000000000000000  0cb81875
 2**0
                  CONTENTS, READONLY, DEBUGGING
 53 .debug_line   019192f6  0000000000000000  0000000000000000  0d057f65
 2**0
                  CONTENTS, READONLY, DEBUGGING
 54 .debug_frame  002d4fe0  0000000000000000  0000000000000000  0e971260
 2**3
                  CONTENTS, READONLY, DEBUGGING
 55 .debug_str    00390822  0000000000000000  0000000000000000  0ec46240
 2**0
                  CONTENTS, READONLY, DEBUGGING
 56 .debug_line_str 00000445  0000000000000000  0000000000000000
0efd6a62  2**0
                  CONTENTS, READONLY, DEBUGGING
 57 .debug_loclists 0176a32c  0000000000000000  0000000000000000
0efd6ea7  2**0
                  CONTENTS, READONLY, DEBUGGING
 58 .debug_rnglists 00382d7a  0000000000000000  0000000000000000
107411d3  2**0
                  CONTENTS, READONLY, DEBUGGING

The debug info hasn't been stripped, so I suspect the packaging spec
file or equivalent - in perhaps trying to preserve the .BTF section -
is preserving debug info too. DWARF needs to be there at BTF
generation time in vmlinux but is usually stripped for non-debug
packages.

FYI we're aiming to make BTF module-loadable via CONFIG_DEBUG_INFO_BTF=m
in the future, I'm hoping to get an RFC patch out for that soon once
other BTF-related issues are sorted. Hope this helps

Alan