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