[cfe-dev] support __attribute__((weak)) for non-primitive types

[Reid Kleckner via cfe-dev]

I think it would be preferable to come up with a new attribute rather than
overloading `__attribute__((weak))` for this purpose.

The weak attribute doesn't seem to apply to functions in the way you seem
to have in mind for aggregates:
  int __attribute__((weak)) f() { return 1;}
  int f() { return 2; } // error, redef

On Tue, Aug 24, 2021 at 12:08 PM Y Song via cfe-dev <cfe-dev at lists.llvm.org>
wrote:

> On Tue, Aug 24, 2021 at 11:30 AM Aaron Ballman <aaron at aaronballman.com>
> wrote:
> >
> > On Tue, Aug 24, 2021 at 1:18 AM Y Song <ys114321 at gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > This is a BPF use case. We would like to check whether
> > > __attribute__((weak)) support for non-primitive types would be
> > > possible in clang or not. For example, if we have two types like
> > >    struct t { int a; } __attribute__((weak));
> > >    struct t { int a; };
> > >
> > >    typedef unsigned __u32;
> > >    typedef unsigned __u32 __attribute__((weak));
> > > the compilation should not fail. It should just ignore weak
> definitions.
> > >
> > > In BPF, to support CO-RE (compile once and run everywhere), we
> > > generate a *generic* vmlinux.h
> > > (
> https://facebookmicrosites.github.io/bpf/blog/2020/02/19/bpf-portability-and-co-re.html
> )
> > > which is included in the bpf program. The bpf loader (libbpf) will
> > > adjust field offsets properly based on host record layout so the same
> > > program can run on different kernels which may have different record
> > > layouts.
> > >
> > > But vmlinux.h does not support macros (and simple static inline helper
> > > functions in kernel header files). Currently, users need to define
> > > these macros and static inline functions explicitly in their bpf
> > > program. What we are thinking is to permit users to include kernel
> > > header files containing these macros/static inline functions. But this
> > > may introduce duplicated types as these types have been defined in
> > > vmlinux.h.
> > >
> > > For example, we may have:
> > >     socket.h:
> > >         struct socket { ... };
> > >         #define TCP    6
> > >     vmlinux.h:
> > >         struct socket { ... };
> > >     bpf.c:
> > >         #include <socket.h>
> > >         #include <vmlinux.h>
> > >         ... TCP ...
> > >
> > > In this case, struct "socket" is defined twice. If we can have
> something like
> > >     bpf.c:
> > >       #pragma clang attribute push (__attribute__((weak)), apply_to =
> record)
> > >       #include <socket.h>
> > >       #pragma clang attribute pop
> > >       #include <vmlinux.h>
> > >         ... TCP ...
> > >
> > >
> > > Then bpf program can get header file macro definitions without copying
> > > explicitly.
> > >
> > > We need support for "apply_to = typedef" in the above pragma, so we
> > > can deal with typedef types as well.
> > >
> > > Another issue is related to what if two types are not compatible. For
> example,
> > >     struct t { int a; } __attribute__((weak));
> > >     struct t { int a; int b; };
> > > I think we could have a flag to control whether we allow incompatible
> > > weak type or not.
> > >
> > > It would be good if I can get some suggestions/directions on whether
> > > such a feature is possible or not for clang frontend.
> >
> > One concern I have is that __attribute__((weak)) originally came from
> > GCC and I don't believe GCC supports this functionality. Are you
> > floating this idea by them as well to see if they're on board with it?
>
> I haven't talked to gcc community about this. Since this is to be
> implemented in clang, we would like to get opinion from clang community
> first.
>
> Right, gcc doesn't support such a functionality.
>
> >
> > As I understand it, this attribute is more about symbols that have
> > been exported and how the linker interacts with them. Does the same
> > concept apply here to type declarations? If not, that may suggest we
>
> You are right here. Currently weak attribute applies to global
> variable and function
> declarations and the attribute is mostly used by the linker.
>
> > should use a separate attribute so as not to confuse the semantics.
>
> How about __attribute__((weaktype))?
> It will clearly indicate this is a "weak" style attribute but for "type".
>
> A similar name "weakref" with the same naming convention is used by
> gcc/clang
> to indicate a weak reference declaration.
>
> >
> > ~Aaron
> >
> > >
> > > Thanks,
> > >
> > > Yonghong
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210824/781f4d50/attachment.html>