Re: duplicate BTF_IDs leading to symbol redefinition errors?

[Jiri Olsa <olsajiri@gmail.com>]

On Thu, Sep 14, 2023 at 05:30:51PM +0900, Masahiro Yamada wrote:

SNIP

> > > so the change is about adding unique id that's basically path of
> > > the object stored in base32 so it could be used as symbol, so we
> > > don't really need to read the actual file
> > >
> > > the problem is when BTF_ID definition like:
> > >
> > > BTF_ID(struct, cgroup)
> > >
> > > translates in 2 separate objects into same symbol name because of
> > > the matching __COUNTER__ macro values (like 380 below)
> > >
> > >   __BTF_ID__struct__cgroup__380
> > >
> > > this change just adds unique id of the path name at the end of the
> > > symbol with:
> > >
> > >   echo -n 'kernel/bpf/helpers' | base32 -w0 --> NNSXE3TFNQXWE4DGF5UGK3DQMVZHG
> > >
> > > so the symbol looks like:
> > >
> > >   __BTF_ID__struct__cgroup__380NNSXE3TFNQXWE4DGF5UGK3DQMVZHG
> > >
> > > and is unique over the sources
> > >
> > > but I still hope we could come up with some better solution ;-)
> >
> > so far the only better solution I could come up with is to use
> > cksum (also from coreutils) instead of base32, which makes the
> > BTF_ID_BASE value compact
> >
> > I'll run test to find out how much it hurts the build time
> >
> > jirka
> 
> 
> 
> Seems a bad idea to me.
> 
> It would fork a new shell and chsum for all files,
> while only a few of them need it.

right, I have a change to limit this on kernel and net directories,
but it's still bad

> 
> Better to consult BTF forks.

perhaps there's better way within kbuild to get unique id/value
for each object file?

thanks,
jirka