https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107844
--- Comment #5 from David Faust <david.faust at oracle dot com> --- (In reply to Andrew Pinski from comment #4) > (In reply to David Faust from comment #3) > > Thanks for the info Andrew. I'll look at __builtin_offsetof. > > > > As for the implementation in clang, I can point to some bits relevant to > > the builtin itself: > > llvm-project/clang/lib/CodeGen/CGBuiltin.cpp > > CodeGenFunction::EmitBPFBuiltinExpr () > > > > llvm-project/llvm/lib/Target/BPF/BPFAbstractMemberAccess.cpp > > BPFAbstractMemberAccess::GetFieldInfo () > > > > But I am less familiar with the surrounding machinery such as their > > parsing and type systems.. > > So I looked (First off I am shocked they don't have target functions to > handle the builtins and every target builtin is handled in that file seems > wrong), and you are handed the AST before folding. This is different from > GCC where it is you are handed it after folding. Aha! I had never realized this difference until now. Thanks for pointing that out! > > So I think we need some special handling in the c (and C++) parser to handle > this. I suspect we want to do the full handling of the builtin > (bpf_core_field_exists) in the parser rather than the macro expanded view of > it too. Similar to how offsetof is handled ... > Of course this will need some modifications to the bpf headers too. And that > solves some other issues too. Yes, I see. I'll have to study the parser a little since I have not touched it before, but the approach makes sense. I wonder if it would be feasible and/or worthwhile to add some sort of TARGET_PARSE_BUILTIN hook to enable this sort of handling for any other targets which may want it..? Maybe that can wait. In any case, thank you very much for the suggestions.
