From: "Alexis Lothoré" <alexis.lothore@bootlin.com>
To: "Ihor Solodrai" <ihor.solodrai@linux.dev>, <dwarves@vger.kernel.org>
Cc: <bpf@vger.kernel.org>, "Alan Maguire" <alan.maguire@oracle.com>,
"Arnaldo Carvalho de Melo" <acme@kernel.org>,
"Alexei Starovoitov" <ast@fb.com>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
"Bastien Curutchet" <bastien.curutchet@bootlin.com>,
<ebpf@linuxfoundation.org>
Subject: Re: [PATCH v2 1/3] btf_encoder: skip functions consuming packed structs passed by value on stack
Date: Fri, 04 Jul 2025 11:01:42 +0200 [thread overview]
Message-ID: <DB35D2MDSOGN.1X8PB5AF5M3KN@bootlin.com> (raw)
In-Reply-To: <8923cd39-a242-4f61-b99e-b5fe5678ee84@linux.dev>
Hello Ihor,
thanks for the prompt feedback and testing !
On Thu Jul 3, 2025 at 8:17 PM CEST, Ihor Solodrai wrote:
> On 7/3/25 2:02 AM, Alexis Lothoré (eBPF Foundation) wrote:
[...]
>> /* do not exclude functions with optimized-out parameters; they
>> * may still be _called_ with the right parameter values, they
>> * just do not _use_ them. Only exclude functions with
>> - * unexpected register use or multiple inconsistent prototypes.
>> + * unexpected register use, multiple inconsistent prototypes or
>> + * uncertain parameters location
>> */
>> - add_to_btf |= !state->unexpected_reg && !state->inconsistent_proto;
>> + add_to_btf |= !state->unexpected_reg && !state->inconsistent_proto && !state->uncertain_parm_loc;
>
>
> Is it possible for a function to have uncertain_parm_loc in one CU,
> but not in another?
>
> If yes, we still don't want the function in BTF, right?
TBH, my understanding about those discrepancies between CUs about the same
functions and how pahole handle them is still a bit fragile. Have you got
any example about how it could be the case ?
If it _can_ happen, I guess you are suggesting to make sure that copies are
compared in saved_functions_combine and their uncertain_loc_parm flag are
aligned. Something like this:
uncertain_parm_loc = a->uncertain_parm_loc | b->uncertain_parm_loc;
[...]
a->uncertain_parm_loc = b->uncertain_parm_loc = uncertain_parm_loc;
>> @@ -2693,6 +2736,9 @@ int btf_encoder__encode_cu(struct btf_encoder *encoder, struct cu *cu, struct co
>> if (!func)
>> continue;
>>
>> + if (ftype__has_uncertain_arg_loc(cu, &fn->proto))
>> + fn->proto.uncertain_parm_loc = 1;
>> +
>> err = btf_encoder__save_func(encoder, fn, func);
>
> I think checking and setting uncertain_parm_loc flag should be done
> inside btf_encoder__save_func(), because that's where we inspect DWARF
> function prototype and add a new btf_encoder_func_state.
ACK, it can be moved there
Thanks,
Alexis
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2025-07-04 9:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-03 9:02 [PATCH v2 0/3] btf_encoder: do not encode functions consuming packed structs on stack Alexis Lothoré (eBPF Foundation)
2025-07-03 9:02 ` [PATCH v2 1/3] btf_encoder: skip functions consuming packed structs passed by value " Alexis Lothoré (eBPF Foundation)
2025-07-03 18:17 ` Ihor Solodrai
2025-07-04 9:01 ` Alexis Lothoré [this message]
2025-07-04 19:59 ` Ihor Solodrai
2025-07-04 21:10 ` Alexis Lothoré
2025-07-04 20:05 ` Ihor Solodrai
2025-07-04 21:12 ` Alexis Lothoré
2025-07-03 9:02 ` [PATCH v2 2/3] tests: add some tests validating skipped functions due to uncertain arg location Alexis Lothoré (eBPF Foundation)
2025-07-03 18:31 ` Ihor Solodrai
2025-07-04 9:06 ` Alexis Lothoré
2025-07-03 9:02 ` [PATCH v2 3/3] gitignore: ignore all the test kmod build-related files Alexis Lothoré (eBPF Foundation)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DB35D2MDSOGN.1X8PB5AF5M3KN@bootlin.com \
--to=alexis.lothore@bootlin.com \
--cc=acme@kernel.org \
--cc=alan.maguire@oracle.com \
--cc=ast@fb.com \
--cc=bastien.curutchet@bootlin.com \
--cc=bpf@vger.kernel.org \
--cc=dwarves@vger.kernel.org \
--cc=ebpf@linuxfoundation.org \
--cc=ihor.solodrai@linux.dev \
--cc=thomas.petazzoni@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.