Re: [PATCH] libbpf: add support to GCC in CORE macro definitions

["Jose E. Marchesi" <jose.marchesi@oracle.com>]

> On Thu, Feb 8, 2024 at 5:07 AM Cupertino Miranda
> <cupertino.miranda@oracle.com> wrote:
>>
>>
>> Hi everyone,
>>
>> This is a patch to make CORE builtin macros work with builtin
>> implementation within GCC.
>>
>> Looking forward to your comments.
>>
>
> Can you please repost it as a proper patch email, not as an attachment?
>
> But generally speaking, is there any way to change/fix GCC to allow a
> much more straightforward way to capture type, similar to how Clang
> does it? I'm not a big fan of extern declarations and using per-file
> __COUNTER__. Externs are globally visible and we can potentially run
> into name conflicts because __COUNTER__ is not globally unique.
>
> And just in general, it seems like this shouldn't require such
> acrobatics.
>
> Jose, do you have any thoughts on this?

Yes the macro is ugly and more elaborated than the clang version, but I
am afraid it is necessary in order to overcome the fact GCC
constant-folds enumerated values at parse-time.

Note however that the expression-statement itself to which the macro
expands is not elaborated, much like the null pointer dereference in the
clang version doesn't get elaborated.  These are just conveyed to the
builtins an the builtins use the TREE (IR in case of clang I guess) to
extract the type from it.

As far as I understand it the extern declaration in the macro is not
declaring an object with extern visibility, so it should not result in
any symbol being defined nor have any impact outside of the compilation
unit.  The __COUNTER__ is there just so you can use the macro more than
once in the same compilation unit, but that's all.

Cuper will correct me if I am wrong.

>
>> Regards,
>> Cupertino
>>