> On Sep 15, 2023, at 1:26 PM, Richard Biener <richard.guent...@gmail.com>
> wrote:
>
>
>
>> Am 15.09.2023 um 17:37 schrieb Qing Zhao <qing.z...@oracle.com>:
>>
>>
>>
>>>> On Sep 15, 2023, at 11:29 AM, Richard Biener <richard.guent...@gmail.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>> Am 15.09.2023 um 17:25 schrieb Qing Zhao <qing.z...@oracle.com>:
>>>>
>>>>
>>>>
>>>>> On Sep 15, 2023, at 8:41 AM, Arsen Arsenović <ar...@aarsen.me> wrote:
>>>>>
>>>>>
>>>>> Qing Zhao <qing.z...@oracle.com> writes:
>>>>>
>>>>>> Even though unsigned integer overflow is well defined, it might be
>>>>>> unintentional, shall we warn user about this?
>>>>>
>>>>> This would be better addressed by providing operators or functions that
>>>>> do overflow checking in the language, so that they can be explicitly
>>>>> used where overflow is unexpected.
>>>>
>>>> Yes, that will be very helpful to prevent unexpected overflow in the
>>>> program in general.
>>>> However, this will mainly benefit new codes.
>>>>
>>>> For the existing C codes, especially large applications, we still need to
>>>> identify all the places
>>>> Where the overflow is unexpected, and fix them.
>>>>
>>>> One good example is linux kernel.
>>>>
>>>>> One could easily imagine a scenario
>>>>> where overflow is not expected in some region of code but is in the
>>>>> larger application.
>>>>
>>>> Yes, that’s exactly the same situation Linux kernel faces now, the
>>>> unexpected Overflow and
>>>> expected wrap-around are mixed together inside one module.
>>>> It’s hard to detect the unexpected overflow under such situation based on
>>>> the current GCC.
>>>
>>> But that’s hardly GCCs fault nor can GCC fix that in any way. Only the
>>> programmer can distinguish both cases.
>>
>> Right, compiler cannot fix this.
>> But can provide some tools to help the user to detect this more
>> conveniently.
>>
>> Right now, GCC provides two set of options for different types:
>>
>> A. Turn the overflow to expected wrap-around (remove UB);
>> B. Detect overflow;
>>
>> A B
>> remove UB -fsanitize=…
>> signed -fwrapv signed-integer-overflow
>> pointer -fwrapv-pointer pointer-overflow (broken in Clang)
>>
>> However, Options in A and B excluded with each other. They cannot mix
>> together for a single file.
>>
>> What’s requested from Kernel is:
>>
>> compiler needs to provide a functionality that can mix these two together
>> for a file.
>>
>> i.e, apply A (convert UB to defined behavior WRAP-AROUND) only to part of
>> the program. And then add -fsnaitize=*overflow to detect all other
>> Unexpected overflows in the program.
>>
>> This is currently missing from GCC, I guess?
>
> How can GCC know which part of the program wants wrapping and which
> sanitizing?
GCC doesn’t know, but the user knows.
Then just provide the user a way to mark part of the program to be wrapping
around and excluded from sanitizing?
Currently, GCC provides
__attribute__(optimize ("wrapv"))
To mark the specific function to be wrapped around.
However, this attribute does not work for linux kernel due to the following
reason:
Attribute optimize should be only used for debugging purpose;
The kernel has banned its usage;
So, a new attribute was requested from Linux kernel security:
request wrap-around behavior for specific function (PR102317)
__attribute__((wrapv))
Is this request reasonable?
Qing
> Richard
>
>> Qing
>>
>>
>>
>>
>>
>>>
>>> Richard
>>>
>>>> Thanks.
>>>>
>>>> Qing
>>>>> --
>>>>> Arsen Arsenović
