All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jose E. Marchesi" <jose.marchesi@oracle.com>
To: Eduard Zingerman <eddyz87@gmail.com>
Cc: Yonghong Song <yonghong.song@linux.dev>,
	bpf@vger.kernel.org, david.faust@oracle.com,
	cupertino.miranda@oracle.com, Yonghong Song <yhs@meta.com>
Subject: Re: BPF selftests and strict aliasing
Date: Mon, 29 Jan 2024 18:05:03 +0100	[thread overview]
Message-ID: <87sf2gnk8w.fsf@oracle.com> (raw)
In-Reply-To: <6819204566bfae73c140938920eeb389d27abad8.camel@gmail.com> (Eduard Zingerman's message of "Mon, 29 Jan 2024 18:15:39 +0200")


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

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.

  reply	other threads:[~2024-01-29 17:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-27 19:59 BPF selftests and strict aliasing Jose E. Marchesi
2024-01-28  2:05 ` Yonghong Song
2024-01-28 12:25   ` Jose E. Marchesi
2024-01-29  5:33     ` Yonghong Song
2024-01-29 16:15       ` Eduard Zingerman
2024-01-29 17:05         ` Jose E. Marchesi [this message]
2024-01-29 18:16           ` Yonghong Song
2024-01-29 18:43             ` Jose E. Marchesi
2024-01-29 21:48               ` Yonghong Song
2024-01-29 21:59                 ` Jose E. Marchesi
2024-01-29 18:12         ` Yonghong Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sf2gnk8w.fsf@oracle.com \
    --to=jose.marchesi@oracle.com \
    --cc=bpf@vger.kernel.org \
    --cc=cupertino.miranda@oracle.com \
    --cc=david.faust@oracle.com \
    --cc=eddyz87@gmail.com \
    --cc=yhs@meta.com \
    --cc=yonghong.song@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.