<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 14, 2021, at 6:44 PM, David Blaikie via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta charset="UTF-8" class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class="Apple-interchange-newline"><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 14, 2021 at 4:54 PM David Rector <<a href="mailto:davrecthreads@gmail.com" class="">davrecthreads@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jun 14, 2021, at 5:33 PM, Y Song via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class=""><div class=""><div class="">On Mon, Jun 14, 2021 at 1:25 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank" class="">dblaikie@gmail.com</a>> wrote:<br class=""><blockquote type="cite" class=""><br class=""><br class=""><br class="">On Mon, Jun 14, 2021 at 12:25 PM Y Song <<a href="mailto:ys114321@gmail.com" target="_blank" class="">ys114321@gmail.com</a>> wrote:<br class=""><blockquote type="cite" class=""><br class="">On Fri, Jun 11, 2021 at 9:59 AM Alexei Starovoitov<br class=""><<a href="mailto:alexei.starovoitov@gmail.com" target="_blank" class="">alexei.starovoitov@gmail.com</a>> wrote:<br class=""><blockquote type="cite" class=""><br class="">On Fri, Jun 11, 2021 at 07:17:32AM -0400, Aaron Ballman wrote:<br class=""><blockquote type="cite" class="">On Thu, Jun 10, 2021 at 8:47 PM Alexei Starovoitov<br class=""><<a href="mailto:alexei.starovoitov@gmail.com" target="_blank" class="">alexei.starovoitov@gmail.com</a>> wrote:<br class=""><blockquote type="cite" class=""><br class="">On Thu, Jun 10, 2021 at 12:42 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank" class="">dblaikie@gmail.com</a>> wrote:<br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class=""><br class="">Any suggestions/preferences for the spelling, Aaron?<br class=""></blockquote><br class="">I don't know this domain particularly well, so takes these suggestions<br class="">with a giant grain of salt:<br class=""><br class="">If the concept is specific to DWARF and you don't think it'll need to<br class="">extend into other debug formats, you could go with `dwarf_annotate`.<br class="">If it's not really a DWARF thing but is more about B[P|T]F, then<br class="">`btf_annotate` or `bpf_annotate` could work, but those may be a bit<br class="">mysterious to folks outside of the domain. If it's a generic debug<br class="">info concept, probably `debug_info_annotate` or something.<br class=""></blockquote><br class=""><br class="">Arguably it can/could be a generic debug info or dwarf thing, but for now we don't have any use for it other than to squirrel info along to BTF/BPF so I'm on the fence about which prefix to use exactly<br class=""><br class=""></blockquote><br class="">A bit more bike shedding colors...<br class=""><br class="">The __rcu and __user annations might be used by the clang itself eventually.<br class="">Currently the "sparse" tool is doing this analysis and warns users<br class="">when __rcu pointer is incorrectly accessed in the kernel C code.<br class="">If clang can do that directly that could be a huge selling point<br class="">for folks to switch from gcc to clang for kernel builds.<br class="">The front-end would treat such annotations as arbitrary string, but<br class="">special "building-linux-kernel-pass" would interpret the semantical context.<br class=""></blockquote><br class="">Are __rcu and __user annotations notionally distinct things from bpf<br class="">(and perhaps each other as well)? Distinct enough that it would make<br class="">sense to use a different attribute name for user source for each need?<br class="">I suspect the answer is yes given that the existing annotations have<br class="">their own names which are distinct, but I don't know this domain<br class="">enough to be sure.<br class=""></blockquote><br class="">__rcu and __user don't overlap. __rcu is not a single annotation though.<br class="">It's a combination of annotations in pointers, functions, macros.<br class="">Some functions have:<br class="">__acquires(rcu)<br class="">another function might have:<br class="">__acquires(rcu_bh)<br class="">There are several flavors of the RCU in the kernel.<br class="">So single __attribute__((rcu_annotate("foo"))) won't work even within RCU scope.<br class="">But if we do:<br class="">struct foo {<br class=""> void * __attribute__((tag("ptr.rcu_bh")) ptr;<br class="">};<br class="">int bar(int) __attribute__((tag("acquires.rcu_bh")) { ... }<br class="">int baz(int) __attribute__((tag("releases.rcu_bh")) { ... }<br class="">int qux(int) __attribute__((tag("acquires.rcu_sched")) { ... }<br class="">...<br class="">The clang pass can parse these strings and correlate one tag to another.<br class="">RCU flavors come and go, so clang cannot hard code the names.<br class=""></blockquote><br class="">Maybe we can name it as "bpf_tag" as it is a "tag" for "bpf" use case?<br class=""><br class="">David, in one of your early emails, you mentioned:<br class=""><br class="">===<br class="">Arguably it can/could be a generic debug info or dwarf thing, but for<br class="">now we don't have any use for it other than to squirrel info along to<br class="">BTF/BPF so I'm on the fence about which prefix to use exactly<br class="">===<br class=""><br class="">and suggests since it might be used in the future for non-bpf things,<br class="">maybe the name could be a little more generic then bpf-specific.<br class=""><br class="">Do you have any suggestions on what name to pick?<br class=""></blockquote><br class=""><br class="">Nah, not especially. bpf_tag sounds OK-ish to me if it suits you.<br class=""></blockquote><br class=""></div></div></blockquote><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">The more generic the better IMO. And, the less the need to parse string literals the better. </div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">Why not simply `<span style="font-family: Menlo;" class="">__attribute__((debuginfo("arg1", "arg2", ...)))</span>`, e.g.:</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">```</div><div style="margin: 0px; font-stretch: normal; line-height: normal; font-family: Menlo;" class=""><span style="-webkit-font-kerning: none;" class="">#define BPF_TAG(...) __attribute__((debuginfo("bpf", __VA_ARGS__)))</span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; font-family: Menlo;" class=""><span style="-webkit-font-kerning: none;" class="">struct foo {</span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; font-family: Menlo;" class=""><span style="-webkit-font-kerning: none;" class=""> void * BPF_TAG("ptr","rcu","bh") ptr;</span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; font-family: Menlo;" class=""><span style="-webkit-font-kerning: none;" class="">};</span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; font-family: Menlo;" class=""><span style="-webkit-font-kerning: none;" class="">#define BPF_RCU_TAG(PFX, ...) BPF(PFX, "rcu", __VA_ARGS__)</span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; font-family: Menlo;" class=""><span style="-webkit-font-kerning: none;" class="">int bar(int) BPF_RCU_TAG("acquires","bh") { ... }</span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; font-family: Menlo;" class=""><span style="-webkit-font-kerning: none;" class="">int baz(int) BPF_RCU_TAG("releases","bh") { ... }</span></div><div style="margin: 0px; font-stretch: normal; line-height: normal; font-family: Menlo;" class=""><span style="-webkit-font-kerning: none;" class="">int qux(int) BPF_RCU_TAG("acquires","sched") { ... }</span></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">```</div></div></div></div></blockquote><div class=""><br class="">Unless Paul & Adrian, etc chime in in agreement of a more general name, like 'debuginfo', I'm inclined to avoid that/go with something bpf specific until there's a broader use case/proposal, something we might be able to/want to encourage GCC to support too. Otherwise we're taking a pretty broad attribute name & choosing its behavior when we don't necessarily have a lot of leverage if GCC ends up using that name for something else.<br class=""></div></div></div></div></blockquote><div><br class=""></div><div>There are definitely use-cases for threading a general string attribute through LLVM IR all the way to DWARF. Recently I thought about how to best encode API Swiftification attributes (e.g., <a href="https://developer.apple.com/documentation/swift/objective-c_and_c_code_customization/renaming_objective-c_apis_for_swift" class="">https://developer.apple.com/documentation/swift/objective-c_and_c_code_customization/renaming_objective-c_apis_for_swift</a>) in DWARF. These are Clang attributes put on (Objective-)C type declarations that tell the Swift compiler how to map C and Objective-C types into Swift. The attributes range from nullability of pointers to renaming types to better fit into the Swift world. Having a generic DWARF facility to encode <i class="">any</i> Clang __attribute__(()) declaration would make this very straightforward to implement.</div><div><br class=""></div><div>Maybe this is a good opportunity to design a generic mechanism that works for all attributes? We probably need to add a little more structure than just encoding a single string with the attribute contents to make the encoding more efficient, but we could probably have something generic enough to be useful across many use-cases.</div><div><br class=""></div><div>Is there any interest in attempting this or do you prefer with targeted extensions for each kind of attribute?</div><div><br class=""></div><div>-- adrian</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_quote"><div class=""><br class="">& as for separate strings - maybe, but I'm not sure what that'll look like in the resulting DWARF, what sort of form would you propose using to encode that? (same question below \/)<br class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="">Sounds good. I will use "bpf_tag" as the starting point now.<br class="">Also, it is possible "bpf_tag" may appear multiple times for the same<br class="">function, declaration etc.<br class=""><br class="">For example,<br class=""> #define __bpf_tag(s) __attribute__((bpf_tag(s)))<br class=""> int g __bpf_tag("str1") __bpf_tag("str2");<br class="">Let us say we introduced a LLVM vendor tag DWARF_AT_LLVM_bpf_tag.<br class=""><br class="">How do you want the above to be represented in dwarf?<br class=""><br class="">My current scheme is to put all bpf_tag's in a string, separated by ",".<br class="">This will make things simpler. So the final output will be<br class=""> DWARF_AT_LLVM_bpf_tag "str1,str2"<br class="">I may need to do a discussion with the kernel folks to use a different<br class="">delimiter than ",", but we still represent all tags with ONE string.<br class=""><br class="">But alternatively, it could be represented as a list of strings like<br class=""> DWARF_AT_LLVM_bpf_tag<br class=""> "str1"<br class=""> "str2"<br class="">is similar to DWARF_AT_location.<br class=""></div></div></blockquote></div></div></blockquote><div class=""><br class=""></div><div class="">What DWARF form were you thinking of using for this? There isn't a built in form that provides encoding for multiple delimited/separated strings that I know of.</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">The first internal representation<br class=""> DWARF_AT_LLVM_bpf_tag "str1,str2"<br class="">should be easier for IR/bitcode read/write and dwarf parsing.<br class=""><br class="">What do you think?<br class="">_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class=""></div></div></blockquote></div><br class=""></div></blockquote></div></div><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">_______________________________________________</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">LLVM Developers mailing list</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a></span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class=""><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></span></div></blockquote></div><br class=""></body></html>