On 12/15/22 10:43 AM, Jose E. Marchesi wrote:
Of the two problems discussed:
1. DW_TAG_LLVM_annotation not being able to denote annotations to
non-pointed based types. clang currently ignores these instances.
We discussed two possible options to deal with this:
1.1 To continue ignoring these cases in the front-end, keep the dwarf
expressiveness limitation, and document it.
1.2 To change DW_TAG_LLVM_annotation so it behaves like a qualifier
DIE (like const, volatile, etc.) so it can apply to any type.
Thanks for the detailed update. Yes, we do want to __tag behaving like
a qualifier.
Today clang only support 'base_type <type_tag> *' style of code.
But we are open to support non-pointer style of tagging like
'base_type <type_tag> global_var'. Because of this, the following
dwarf output should be adopted:
C: int __tag1 * __tag2 * p;
dwarf: ptr -> __tag2 --> ptr -> __tag1 -> int
or
C: int __tag1 g;
dwarf: var_g -> __tag1 --> int
The above format *might* require particular dwarf tools to add support
for __tag attribute. But I think it is a good thing in the long run
esp. if we might add support to non-pointer types. In current
implementation, dwarf tools can simply ignore the children of ptr
which they may already do it.
2. The ordering problem: sparse annotations order differently than
GNU/C99 compiler attributes. Therefore translating 1-to-1 from
sparse annotations to compiler attributes results in attributes with
different syntax than normal compiler attributes.
This was accepted in clang.
But found resistance in GCC when we sent the first patch series.
During the meeting we went thru several possible ways of dealing with
this problem, but we didn't reach any conclusion on what to do, since
the time ran out.
We agreed to continue the discussion at the BPF office hours next 5
January 2023.
In the meanwhile, below in this email is a slightly updated version of
the material used to go thru the topics during the discussion. If there
is any mistake or if you see that our understanding of the
problem/situation is not correct, please point it out. If you want to
add more information, please do so by replying to this thread.
Finally, it was agreed that we (GCC BPF hackers) would send Yonghong our
github accounts so he can subscribe us to notifications in the llvm
phabricator, so we can be aware of potentially ABI/breaking changes at
the time they are discussed, and not afterwards scanning bpf@vger. I
alredy sent him the information.
Thank you for your time today. It is appreciated.
[...]
