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

[Y Song via cfe-dev]

On Tue, Aug 24, 2021 at 2:03 PM Reid Kleckner <rnk at google.com> wrote:
>
>
> 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

Right, I propose to use __attribute__((weaktype)) to indicate the
attribute is for types.
Please let me know if you have any other suggestions.

>
> 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