Re: [PATCH bpf-next v3 12/15] libbpf: rewrite btf datasec names starting from '?'

[Eduard Zingerman <eddyz87@gmail.com>]

On Tue, 2024-03-05 at 12:03 -0800, Andrii Nakryiko wrote:
[...]

> > @@ -2922,6 +2929,8 @@ static int bpf_object__sanitize_btf(struct bpf_object *obj, struct btf *btf)
> >                         char *name;
> > 
> >                         name = (char *)btf__name_by_offset(btf, t->name_off);
> > +                       if (*name == '?')
> > +                               *name++ = '_';
> >                         while (*name) {
> >                                 if (*name == '.')
> 
> let's just extend this to `if (*name == '.' || *name == '?')` ?

Ok.

> > @@ -2938,6 +2947,25 @@ static int bpf_object__sanitize_btf(struct bpf_object *obj, struct btf *btf)
> >                                 vt = (void *)btf__type_by_id(btf, v->type);
> >                                 m->name_off = vt->name_off;
> >                         }
> > +               } else if (!has_qmark_datasec && btf_is_datasec(t) &&
> > +                          starts_with_qmark(btf__name_by_offset(btf, t->name_off))) {
> > +                       /* remove '?' prefix and add '.optional' suffix for
> > +                        * DATASEC names staring from '?':
> > +                        *
> > +                        *   DATASEC ?.foo -> DATASEC .foo.optional
> > +                        */
> > +                       const char *name;
> > +                       char buf[256];
> > +                       int str;
> > +
> > +                       name = btf__name_by_offset(btf, t->name_off);
> > +                       snprintf(buf, sizeof(buf), "%s.optional", &name[1] /* skip '?' */);
> > +                       str = btf__add_str(btf, buf);
> > +                       if (str < 0)
> > +                               return str;
> > +
> > +                       t = (struct btf_type *)btf__type_by_id(btf, i);
> > +                       t->name_off = str;
> 
> let's keep it simpler, just do in-place name sanitization like we did
> for !has_datasec case? It's fine if "?.struct_ops" becomes
> "_.struct_ops", kernel doesn't care and doesn't assign any special
> meaning to DATASEC names

Well, in theory this string is shared between several locations,
though this is probably highly unlikely.
Anyways, I made requested change.

[...]