On 3/14/24 10:16, Jose E. Marchesi wrote:
>
> Hi David.
>
>> Change the BPF backend to define INT8_TYPE with an explicit sign, rather
>> than a plain char. This is in line with other targets and removes the
>> risk of int8_t being affected by the signedness of the plain char type
>> of the host system.
>
> OK.
>
> I would add to the commit message that the motivation for this change is
> that even if `char' is defined to be signed in BPF targets, some BPF
> programs use the (mal)practice of including internal libc headers
> indirectly via kernel headers and that may trigger compilation errors
> regarding redefinitions of types.
Thanks, added this to the commit message and pushed.
>
> Thanks for the patch!
>
>>
>> Tested on x86_64-linux-gnu host for bpf-unknown-none.
>> Sanity checked compiling Linux kernel BPF selftests.
>>
>> gcc/
>>
>> * config/bpf/bpf.h (INT8_TYPE): Change to signed char.
>> ---
>> gcc/config/bpf/bpf.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gcc/config/bpf/bpf.h b/gcc/config/bpf/bpf.h
>> index f107a5a4c34..3cc5daa1b58 100644
>> --- a/gcc/config/bpf/bpf.h
>> +++ b/gcc/config/bpf/bpf.h
>> @@ -99,7 +99,7 @@
>>
>> #define SIG_ATOMIC_TYPE "char"
>>
>> -#define INT8_TYPE "char"
>> +#define INT8_TYPE "signed char"
>> #define INT16_TYPE "short int"
>> #define INT32_TYPE "int"
>> #define INT64_TYPE "long int"