> On Fri, 2025-01-03 at 01:16 +0100, Jose E. Marchesi wrote:
>
> [...]
>
>> Yes, in the GCC BPF backend we are using
>>
>> use_gcc_stdint=provide
>>
>> which makes GCC to provide the version of stdint.h that assumes
>> freestanding ("baremetal") mode. If we changed it to use
>>
>> use_gcc_stdint=wrap
>>
>> then it would install a stdint.h that does somethins similar to what
>> clang does, at least in hosts providing C99 headers (note the lack of
>> __has_include_next):
>>
>> #ifndef _GCC_WRAP_STDINT_H
>> #if __STDC_HOSTED__
>> # if defined __cplusplus && __cplusplus >= 201103L
>> # undef __STDC_LIMIT_MACROS
>> # define __STDC_LIMIT_MACROS
>> # undef __STDC_CONSTANT_MACROS
>> # define __STDC_CONSTANT_MACROS
>> # endif
>> #pragma GCC diagnostic push
>> #pragma GCC diagnostic ignored "-Wpedantic" // include_next
>> # include_next <stdint.h>
>> #pragma GCC diagnostic pop
>> #else
>> # include "stdint-gcc.h"
>> #endif
>> #define _GCC_WRAP_STDINT_H
>> #endif
>>
>> We could switch to "wrap" to align with clang, but in that case it would
>> be up to the user to provide a "host" stdint.h that contains sensible
>> definitions for BPF. The kernel selftests, for example, would need to
>> do so to avoid including /usr/include/stdint.h that more likely than not
>> will provide incorrect definitions for int64_t and friends...
>
> Would it be possible to push a branch that uses '=wrap' thing
> somewhere? So that it could be further tested to see if there are
> more issues with selftests.
No need. After reflecting a bit I can't see why the requirements on the
"host" stdint.h must be different for BPF than for any other target: its
contents must match the expectations of the compiler for the arch. If
it doesn't... well, it is not the responsibility of the compiler to
assure that. I will install a patch to switch to the wrapper stdint.h.
