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

[Cupertino Miranda <cupertino.miranda@oracle.com>]

Jose E. Marchesi writes:

>> 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?
Apologies for that. Was unaware of the requirement.
>>
>> 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 tried, but due to GCC front-end specifics it is not possible without
overly change how GCC front-end works.

It is not only the constant folding of the enums as Jose suggests, but
also the cast of 0 gets optimized away by the parser itself. Leaving the
builtins expansion without a clue of the precise type used in a field
expression, as an example.

>> 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.

The symbols with the __COUNTER__ are consumed by the builtins expansion
and will never reach the output.

>>
>> 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
>>>