<div dir="ltr"><div dir="ltr"><br></div><br><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">davrecthreads@gmail.com</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"><div style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On Jun 14, 2021, at 5:33 PM, Y Song via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:</div><br><div><div>On Mon, Jun 14, 2021 at 1:25 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br><blockquote type="cite"><br><br><br>On Mon, Jun 14, 2021 at 12:25 PM Y Song <<a href="mailto:ys114321@gmail.com" target="_blank">ys114321@gmail.com</a>> wrote:<br><blockquote type="cite"><br>On Fri, Jun 11, 2021 at 9:59 AM Alexei Starovoitov<br><<a href="mailto:alexei.starovoitov@gmail.com" target="_blank">alexei.starovoitov@gmail.com</a>> wrote:<br><blockquote type="cite"><br>On Fri, Jun 11, 2021 at 07:17:32AM -0400, Aaron Ballman wrote:<br><blockquote type="cite">On Thu, Jun 10, 2021 at 8:47 PM Alexei Starovoitov<br><<a href="mailto:alexei.starovoitov@gmail.com" target="_blank">alexei.starovoitov@gmail.com</a>> wrote:<br><blockquote type="cite"><br>On Thu, Jun 10, 2021 at 12:42 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br><blockquote type="cite"><br><blockquote type="cite"><blockquote type="cite"><br><br>Any suggestions/preferences for the spelling, Aaron?<br></blockquote><br>I don't know this domain particularly well, so takes these suggestions<br>with a giant grain of salt:<br><br>If the concept is specific to DWARF and you don't think it'll need to<br>extend into other debug formats, you could go with `dwarf_annotate`.<br>If it's not really a DWARF thing but is more about B[P|T]F, then<br>`btf_annotate`  or `bpf_annotate` could work, but those may be a bit<br>mysterious to folks outside of the domain. If it's a generic debug<br>info concept, probably `debug_info_annotate` or something.<br></blockquote><br><br>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><br></blockquote><br>A bit more bike shedding colors...<br><br>The __rcu and __user annations might be used by the clang itself eventually.<br>Currently the "sparse" tool is doing this analysis and warns users<br>when __rcu pointer is incorrectly accessed in the kernel C code.<br>If clang can do that directly that could be a huge selling point<br>for folks to switch from gcc to clang for kernel builds.<br>The front-end would treat such annotations as arbitrary string, but<br>special "building-linux-kernel-pass" would interpret the semantical context.<br></blockquote><br>Are __rcu and __user annotations notionally distinct things from bpf<br>(and perhaps each other as well)? Distinct enough that it would make<br>sense to use a different attribute name for user source for each need?<br>I suspect the answer is yes given that the existing annotations have<br>their own names which are distinct, but I don't know this domain<br>enough to be sure.<br></blockquote><br>__rcu and __user don't overlap. __rcu is not a single annotation though.<br>It's a combination of annotations in pointers, functions, macros.<br>Some functions have:<br>__acquires(rcu)<br>another function might have:<br>__acquires(rcu_bh)<br>There are several flavors of the RCU in the kernel.<br>So single __attribute__((rcu_annotate("foo"))) won't work even within RCU scope.<br>But if we do:<br>struct foo {<br>  void * __attribute__((tag("ptr.rcu_bh")) ptr;<br>};<br>int bar(int) __attribute__((tag("acquires.rcu_bh")) { ... }<br>int baz(int) __attribute__((tag("releases.rcu_bh")) { ... }<br>int qux(int) __attribute__((tag("acquires.rcu_sched")) { ... }<br>...<br>The clang pass can parse these strings and correlate one tag to another.<br>RCU flavors come and go, so clang cannot hard code the names.<br></blockquote><br>Maybe we can name it as "bpf_tag" as it is a "tag" for "bpf" use case?<br><br>David, in one of your early emails, you mentioned:<br><br>===<br>Arguably it can/could be a generic debug info or dwarf thing, but for<br>now we don't have any use for it other than to squirrel info along to<br>BTF/BPF so I'm on the fence about which prefix to use exactly<br>===<br><br>and suggests since it might be used in the future for non-bpf things,<br>maybe the name could be a little more generic then bpf-specific.<br><br>Do you have any suggestions on what name to pick?<br></blockquote><br><br>Nah, not especially. bpf_tag sounds OK-ish to me if it suits you.<br></blockquote><br></div></div></blockquote><div><br></div><div><div style="margin:0px;font-stretch:normal;line-height:normal">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"><br></div><div style="margin:0px;font-stretch:normal;line-height:normal">Why not simply `<span style="font-family:Menlo">__attribute__((debuginfo("arg1", "arg2", ...)))</span>`, e.g.:</div><div style="margin:0px;font-stretch:normal;line-height:normal;min-height:14px"><br></div><div style="margin:0px;font-stretch:normal;line-height:normal">```</div><div style="margin:0px;font-stretch:normal;line-height:normal;font-family:Menlo"><span style="font-kerning:none">#define BPF_TAG(...) __attribute__((debuginfo("bpf", __VA_ARGS__)))</span></div><div style="margin:0px;font-stretch:normal;line-height:normal;font-family:Menlo"><span style="font-kerning:none">struct foo {</span></div><div style="margin:0px;font-stretch:normal;line-height:normal;font-family:Menlo"><span style="font-kerning:none"> void * BPF_TAG("ptr","rcu","bh") ptr;</span></div><div style="margin:0px;font-stretch:normal;line-height:normal;font-family:Menlo"><span style="font-kerning:none">};</span></div><div style="margin:0px;font-stretch:normal;line-height:normal;font-family:Menlo"><span style="font-kerning:none">#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"><span style="font-kerning:none">int bar(int) BPF_RCU_TAG("acquires","bh") { ... }</span></div><div style="margin:0px;font-stretch:normal;line-height:normal;font-family:Menlo"><span style="font-kerning:none">int baz(int) BPF_RCU_TAG("releases","bh") { ... }</span></div><div style="margin:0px;font-stretch:normal;line-height:normal;font-family:Menlo"><span style="font-kerning:none">int qux(int) BPF_RCU_TAG("acquires","sched") { ... }</span></div><div style="margin:0px;font-stretch:normal;line-height:normal">```</div></div></div></div></blockquote><div><br>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><br>& 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> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><br><blockquote type="cite"><div><div>Sounds good. I will use "bpf_tag" as the starting point now.<br>Also, it is possible "bpf_tag" may appear multiple times for the same<br>function, declaration etc.<br><br>For example,<br>  #define __bpf_tag(s) __attribute__((bpf_tag(s)))<br>  int g __bpf_tag("str1") __bpf_tag("str2");<br>Let us say we introduced a LLVM vendor tag DWARF_AT_LLVM_bpf_tag.<br><br>How do you want the above to be represented in dwarf?<br><br>My current scheme is to put all bpf_tag's in a string, separated by ",".<br>This will make things simpler. So the final output will be<br>     DWARF_AT_LLVM_bpf_tag  "str1,str2"<br>I may need to do a discussion with the kernel folks to use a different<br>delimiter than ",", but we still represent all tags with ONE string.<br><br>But alternatively, it could be represented as a list of strings like<br>   DWARF_AT_LLVM_bpf_tag<br>             "str1"<br>             "str2"<br>is similar to DWARF_AT_location.<br></div></div></blockquote></div></div></blockquote><div><br></div><div>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> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><blockquote type="cite"><div><div><br>The first internal representation<br>   DWARF_AT_LLVM_bpf_tag  "str1,str2"<br>should be easier for IR/bitcode read/write and dwarf parsing.<br><br>What do you think?<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" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br></div></div></blockquote></div><br></div></blockquote></div></div>