On Tue, Jun 21, 2022 at 2:11 PM Daniel Müller <deso@xxxxxxxxxx> wrote:
>
> On Tue, Jun 21, 2022 at 11:44:17AM -0700, Alexei Starovoitov wrote:
> > On Tue, Jun 21, 2022 at 9:46 AM Daniel Müller <deso@xxxxxxxxxx> wrote:
> > >
> > > On Mon, Jun 20, 2022 at 04:59:19PM -0700, Alexei Starovoitov wrote:
> > > > On Mon, Jun 20, 2022 at 11:17:10PM +0000, Daniel Müller wrote:
> > > > > +int bpf_core_types_match(const struct btf *local_btf, __u32 local_id,
> > > > > + const struct btf *targ_btf, __u32 targ_id)
> > > > > +{
> > > >
> > > > The libbpf and kernel support for types_match looks nearly identical.
> > > > Maybe put in tools/lib/bpf/relo_core.c so it's one copy for both?
> > >
> > > Thanks for the suggestion. Yes, at least for parts we should probably do it.
> > >
> > > Would you happen to know why that has not been done for
> > > bpf_core_types_are_compat equally? Is it because of the recursion level
> > > tracking that is only present in the kernel? I'd think that similar reasoning
> > > applies here.
> >
> > Historical. Probably should be combined.
> > Code duplication is the source of all kinds of maintenance issues
> > and subtle bugs.
>
> Certainly. I noticed that btf.c's bpf_core_types_are_compat uses direct equality
> check of the local and target kind while libbpf.c's version utilizes
> btf_kind_core_compat, which treats enum and enum64 as compatible. I suspect that
> may be a bug in the former.
Great catch. Indeed that does look like a bug that slipped in
due to code duplication :(
> Will move the implementation then. Thanks!
>
> Cc: Yonghong Song <yhs@xxxxxx>
