public inbox for dwarves@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/1] pahole: When trying to encode BTF avoid DWARF less files
@ 2025-04-02 20:35 Arnaldo Carvalho de Melo
  2025-04-03 18:40 ` Alan Maguire
  0 siblings, 1 reply; 5+ messages in thread
From: Arnaldo Carvalho de Melo @ 2025-04-02 20:35 UTC (permalink / raw)
  To: Alan Maguire; +Cc: dwarves

Make sure only DWARF is expected when encoding BTF. In time BTF will
also be accepted, to fixup or augment info produced by some producer, be
it gcc, clang, pahole or some other tool, for now, avoid trying to use
BTF when DWARF isn't available.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 pahole.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/pahole.c b/pahole.c
index af3e1cfe224dd14a..f247ff5e88feeb95 100644
--- a/pahole.c
+++ b/pahole.c
@@ -3493,6 +3493,14 @@ int main(int argc, char *argv[])
 		goto out;
 	}
 
+	// Right now encoding BTF has to be from DWARF, so enforce that, otherwise
+	// the loading process can fall back to other formats, BTF being the case
+	// and as this is at this point unintended, avoid that.
+	// Next we need to just skip object files that don't have the format we
+	// expect as the source for BTF encoding, i.e. no DWARF, no BTF, no problema.
+	if (btf_encode && conf_load.format_path == NULL)
+		conf_load.format_path = "dwarf";
+
 	if (show_running_kernel_vmlinux) {
 		const char *vmlinux = vmlinux_path__find_running_kernel();
 
-- 
2.49.0


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH 1/1] pahole: When trying to encode BTF avoid DWARF less files
  2025-04-02 20:35 [PATCH 1/1] pahole: When trying to encode BTF avoid DWARF less files Arnaldo Carvalho de Melo
@ 2025-04-03 18:40 ` Alan Maguire
  2025-04-04 19:22   ` Arnaldo Carvalho de Melo
  2025-04-08 10:14   ` Alan Maguire
  0 siblings, 2 replies; 5+ messages in thread
From: Alan Maguire @ 2025-04-03 18:40 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo; +Cc: dwarves

On 02/04/2025 21:35, Arnaldo Carvalho de Melo wrote:
> Make sure only DWARF is expected when encoding BTF. In time BTF will
> also be accepted, to fixup or augment info produced by some producer, be
> it gcc, clang, pahole or some other tool, for now, avoid trying to use
> BTF when DWARF isn't available.
> 
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> ---
>  pahole.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/pahole.c b/pahole.c
> index af3e1cfe224dd14a..f247ff5e88feeb95 100644
> --- a/pahole.c
> +++ b/pahole.c
> @@ -3493,6 +3493,14 @@ int main(int argc, char *argv[])
>  		goto out;
>  	}
>  
> +	// Right now encoding BTF has to be from DWARF, so enforce that, otherwise
> +	// the loading process can fall back to other formats, BTF being the case
> +	// and as this is at this point unintended, avoid that.
> +	// Next we need to just skip object files that don't have the format we
> +	// expect as the source for BTF encoding, i.e. no DWARF, no BTF, no problema.
> +	if (btf_encode && conf_load.format_path == NULL)
> +		conf_load.format_path = "dwarf";
> +
>  	if (show_running_kernel_vmlinux) {
>  		const char *vmlinux = vmlinux_path__find_running_kernel();
>  

LGTM

Acked-by: Alan Maguire <alan.maguire@oracle.com>

In the same spirit, should we error out if the format path is explicitly
set to anything other than DWARF for now when btf_encode is set?

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 1/1] pahole: When trying to encode BTF avoid DWARF less files
  2025-04-03 18:40 ` Alan Maguire
@ 2025-04-04 19:22   ` Arnaldo Carvalho de Melo
  2025-04-04 19:37     ` Arnaldo Carvalho de Melo
  2025-04-08 10:14   ` Alan Maguire
  1 sibling, 1 reply; 5+ messages in thread
From: Arnaldo Carvalho de Melo @ 2025-04-04 19:22 UTC (permalink / raw)
  To: Alan Maguire; +Cc: dwarves, Andrii Nakryiko, Yonghong Song, Alexei Starovoitov

On Thu, Apr 03, 2025 at 07:40:19PM +0100, Alan Maguire wrote:
> On 02/04/2025 21:35, Arnaldo Carvalho de Melo wrote:
> > +	// Right now encoding BTF has to be from DWARF, so enforce that, otherwise
> > +	// the loading process can fall back to other formats, BTF being the case
> > +	// and as this is at this point unintended, avoid that.
> > +	// Next we need to just skip object files that don't have the format we
> > +	// expect as the source for BTF encoding, i.e. no DWARF, no BTF, no problema.
> > +	if (btf_encode && conf_load.format_path == NULL)
> > +		conf_load.format_path = "dwarf";

> >  	if (show_running_kernel_vmlinux) {
> >  		const char *vmlinux = vmlinux_path__find_running_kernel();
 
> LGTM
 
> Acked-by: Alan Maguire <alan.maguire@oracle.com>

> In the same spirit, should we error out if the format path is explicitly
> set to anything other than DWARF for now when btf_encode is set?

Probably, but I focused just on this part as I'm trying to follow up on
an idea I described to folks about doing the BTF encoding right after
the .o file is generated, to try and exploit all being in memory and the
natural parallelism of the kernel build process.

If DWARF isn't asked for, which some developers do to avoid having tons
of things hitting the disk, then this gets discarded right away, the
kernel build patch I have right now is super simple and doesn't trow
away DWARF yet:

acme@x1:~/git/linux$ git diff
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 4d543054f72356a4..02a595b82b299151 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -313,7 +313,7 @@ cmd_ld_single = $(if $(objtool-enabled)$(is-single-obj-m), ; $(LD) $(ld_flags) -
 endif
 
 quiet_cmd_cc_o_c = CC $(quiet_modtag)  $@
-      cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $< \
+      cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $< && ${PAHOLE} --btf_encode ${PAHOLE_FLAGS} $@ \
                $(cmd_ld_single) \
                $(cmd_objtool)
 
acme@x1:~/git/linux$

With a the above patch and the following:

acme@x1:~/git/pahole$ git show
commit ee3e75da682eb6bcc191127ea4324677ca2ab7c4 (HEAD -> master)
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Thu Apr 3 15:28:35 2025 -0300

    pahole: Don't fail if no DWARF is available when encoding BTF, just skip
    
    While building the kernel there are a few files that have no DWARF and
    thus needs to get skipped while doing early BTF generation, i.e. per .o
    file instead of vmlinux. Things like arch/x86/purgatory/purgatory.c.
    
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

diff --git a/pahole.c b/pahole.c
index f34e1ecd5542c245..59b7418e3eff89e5 100644
--- a/pahole.c
+++ b/pahole.c
@@ -3609,6 +3609,11 @@ try_sole_arg_as_class_names:
 
        err = cus__load_files(cus, &conf_load, argv + remaining);
        if (err != 0) {
+               if (btf_encode && strcmp(conf_load.format_path, "dwarf") == 0) {
+                       // Assume no DWARF is available and thus just skip this object file
+                       goto out_ok;
+               }
+
                if (class_name == NULL && !btf_encode && !ctf_encode) {
                        class_name = argv[remaining];
 
acme@x1:~/git/pahole$ 

I end up with a vmlinux.o that has .BTF file that combines all the .BTF
for the .o files that comprise vmlinux and then the next step is to use
some --btf_feature=dedup_archive that will basically notice that no
DWARF to BTF is needed, just make btf_parse_elf() to see that the .BTF
section is bigger than what its in the btf_header and then go on in a
loop using btf__add_btf() to go on merging all BTFs to then do the
dedup.

This process is kinda what will happen when gcc -gbtf takes place, i.e.
its generated by the compiler, then after the linker merges all of the
.BTF files (as it does with my patches) it will do the dedup, be it in
the linker, compiler or using libbpf or libctf or whatever other method.

So doing it now is paving the way for this future and may end up
speeding up building kernels while we wait for the whole cc+ld doing it
gets in place and is dependable.

There are issues with the above that needs to be addressed after we have
some basic stuff in place, which I'm getting to, but lets see if I (or
somebody else with less distractions tham myself) do it.

Some numbers:

acme@x1:~/git/pahole$ readelf -SW ../build/v6.14.0+/vmlinux.o  | grep .BTF
  [125] .BTF_ids          PROGBITS        0000000000000000 2a701f8 001178 00   A  0   0  1
  [253] .BTF              PROGBITS        0000000000000000 3ac86c8 15b07fe1 00      0   0  1
acme@x1:~/git/pahole$

363.888.609

acme@number:~$ ls -lah /sys/kernel/btf/vmlinux 
-r--r--r--. 1 root root 6.466.451 Apr  4 14:49 /sys/kernel/btf/vmlinux
acme@number:~$

Way more, as its not deduped, if we ask pahole to pretty print it, it
will see just the first BTF header:

acme@x1:~/git/pahole$ pahole -F btf ../build/v6.14.0+/vmlinux.o | wc -l
12080
acme@x1:~/git/pahole$ pahole -F dwarf ../build/v6.14.0+/vmlinux.o | wc -l
167204
acme@x1:~/git/pahole$

I.e. not dedup'ed

For builds without CONFIG_DEBUG_INFO=y, just with
CONFIG_DEBUG_INFO_BTF=y, which isn't possible now, but should be for
people not wanting DWARF, when using a compiler that doesn't produce BTF
for vmlinux (or produces bad BTF and you want to avoid it, a transition,
point in time situation), this:

-      cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $< \
+      cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $< && ${PAHOLE} --btf_encode ${PAHOLE_FLAGS} $@ \

should additionally strip DWARF after --btf_encode.

- Arnaldo

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH 1/1] pahole: When trying to encode BTF avoid DWARF less files
  2025-04-04 19:22   ` Arnaldo Carvalho de Melo
@ 2025-04-04 19:37     ` Arnaldo Carvalho de Melo
  0 siblings, 0 replies; 5+ messages in thread
From: Arnaldo Carvalho de Melo @ 2025-04-04 19:37 UTC (permalink / raw)
  To: Alan Maguire; +Cc: dwarves, Andrii Nakryiko, Yonghong Song, Alexei Starovoitov

On Fri, Apr 04, 2025 at 04:22:25PM -0300, Arnaldo Carvalho de Melo wrote:
> On Thu, Apr 03, 2025 at 07:40:19PM +0100, Alan Maguire wrote:
> > In the same spirit, should we error out if the format path is explicitly
> > set to anything other than DWARF for now when btf_encode is set?
 
> Probably, but I focused just on this part as I'm trying to follow up on
> an idea I described to folks about doing the BTF encoding right after

While at LSFMM/BPF in Montreal, that is.

- Arnaldo

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 1/1] pahole: When trying to encode BTF avoid DWARF less files
  2025-04-03 18:40 ` Alan Maguire
  2025-04-04 19:22   ` Arnaldo Carvalho de Melo
@ 2025-04-08 10:14   ` Alan Maguire
  1 sibling, 0 replies; 5+ messages in thread
From: Alan Maguire @ 2025-04-08 10:14 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo; +Cc: dwarves

On 03/04/2025 19:40, Alan Maguire wrote:
> On 02/04/2025 21:35, Arnaldo Carvalho de Melo wrote:
>> Make sure only DWARF is expected when encoding BTF. In time BTF will
>> also be accepted, to fixup or augment info produced by some producer, be
>> it gcc, clang, pahole or some other tool, for now, avoid trying to use
>> BTF when DWARF isn't available.
>>
>> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>> ---
>>  pahole.c | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/pahole.c b/pahole.c
>> index af3e1cfe224dd14a..f247ff5e88feeb95 100644
>> --- a/pahole.c
>> +++ b/pahole.c
>> @@ -3493,6 +3493,14 @@ int main(int argc, char *argv[])
>>  		goto out;
>>  	}
>>  
>> +	// Right now encoding BTF has to be from DWARF, so enforce that, otherwise
>> +	// the loading process can fall back to other formats, BTF being the case
>> +	// and as this is at this point unintended, avoid that.
>> +	// Next we need to just skip object files that don't have the format we
>> +	// expect as the source for BTF encoding, i.e. no DWARF, no BTF, no problema.
>> +	if (btf_encode && conf_load.format_path == NULL)
>> +		conf_load.format_path = "dwarf";
>> +
>>  	if (show_running_kernel_vmlinux) {
>>  		const char *vmlinux = vmlinux_path__find_running_kernel();
>>  
> 
> LGTM
> 
> Acked-by: Alan Maguire <alan.maguire@oracle.com>
> 

applied to the next branch of

https://git.kernel.org/pub/scm/devel/pahole/pahole.git/

thanks!

Alan

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2025-04-08 10:14 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-04-02 20:35 [PATCH 1/1] pahole: When trying to encode BTF avoid DWARF less files Arnaldo Carvalho de Melo
2025-04-03 18:40 ` Alan Maguire
2025-04-04 19:22   ` Arnaldo Carvalho de Melo
2025-04-04 19:37     ` Arnaldo Carvalho de Melo
2025-04-08 10:14   ` Alan Maguire

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox