Re: BPF selftests and strict aliasing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 1/29/24 9:05 AM, Jose E. Marchesi wrote:
On Sun, 2024-01-28 at 21:33 -0800, Yonghong Song wrote:
[...]
I tried below example with the above prog/dynptr_fail.c case with gcc 11.4
for native x86 target and didn't trigger the warning. Maybe this requires
latest gcc? Or test C file is not sufficient enough to trigger the warning?

[~/tmp1]$ cat t.c
struct t {
    char a;
    short b;
    int c;
};
void init(struct t *);
long foo() {
    struct t dummy;
    init(&dummy);
    return *(int *)&dummy;
}
[~/tmp1]$ gcc -Wall -Werror -O2 -g -Wno-compare-distinct-pointer-types -c t.c
[~/tmp1]$ gcc --version
gcc (GCC) 11.4.1 20230605 (Red Hat 11.4.1-2)
I managed to trigger this warning for gcc 13.2.1:

     $ gcc -fstrict-aliasing -Wstrict-aliasing=1 -c test-punning.c -o /dev/null
     test-punning.c: In function ‘foo’:
     test-punning.c:10:19: warning: dereferencing type-punned pointer might break strict-aliasing rules [-Wstrict-aliasing]
        10 |    return *(int *)&dummy;
           |                   ^~~~~~
Note the -Wstrict-aliasing=1 option, w/o =1 suffix it does not trigger.

Grepping words "strict-aliasing", "strictaliasing", "strict_aliasing"
through clang code-base does not show any diagnostic related tests or
detection logic. It appears to me clang does not warn about strict
aliasing violations at all and -Wstrict-aliasing=* are just stubs at
the moment.
Detecting strict aliasing violations can only be done by looking at
particular code constructions (casts immediately followed by
dereferencing for example) so GCC provides these three levels: 1, 2, and
3 which is the default.  Level 1 can result in false positives (hence
the "might" in the warning message) while higher levels have less false
positives, but will likely miss lots of real positives.

clang has not implemented this yet.


In this case, it seems to me clear that a pointer to int does not alias
a pointer to struct t.  So I would say, in this little program
strict-aliasing=1 catches a real positive, while strict-aliasing=3
misses a real positive.

This make sense. But could you pose the exact bpf compilation command
line which triggers strict-aliasing warning? Does the compiler command
line have -fstrict-aliasing?





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux