From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay.tugraz.at (mailrelay.tugraz.at [129.27.2.202]) by sourceware.org (Postfix) with ESMTPS id F10DF3858D37 for ; Thu, 26 Oct 2023 08:15:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F10DF3858D37 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=tugraz.at Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tugraz.at ARC-Filter: OpenARC Filter v1.0.0 sourceware.org F10DF3858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=129.27.2.202 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698308117; cv=none; b=fmp1dLrqDPGyZ2fZ8syqmPuNXi79m5ejBPe/5qmsyk2oRL5QbDcJ2e//kWehfjnf5PTVFV/pBRV9zKFgABpXYnkbHeLLiZ7Wzf0soquNkxP7V6qY7+5sj0qkyNHkSzvcJ63ApI01bR5HlhcjBsl/8poyVbZm10tGprrzK+8fHI4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698308117; c=relaxed/simple; bh=yM/kTqfWhW5kaRywTprc5299sOIzqEiH7AuhtXtO82A=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=YjMLBR2m7Fp7Ddey4PvJpmQkta1Lr4NVnxjQWuxWPsG0mCJr8WSyebSdyj0gjWq9T6p8VTau3ugwYUFe1PCIlR3JVAq7+vZCaYqsscAgRor03vF06NQv93sOJrRTUCsIum1F+uDLLUtTHiFJ5B7bEYYzn4wSe/qASRXcOVg90/8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from vra-169-81.tugraz.at (vra-169-81.tugraz.at [129.27.169.81]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4SGJWL6LpGz3wxq; Thu, 26 Oct 2023 10:15:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1698308112; bh=GNHO9z5U0LsDUh36J9fl09ohXmqD7esSRd9Jf+tIMPQ=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=DfVh7JZLFrBraoDKmGW1C7T3im3gJmCdVbYBW0/+/Hz8kPoKILFMsicnFCv2D9fi5 hUL5b0zNbd8H8XhgvgRoXEIvFaLbG0xpH0NCQN1U4i6gX1yMotkaA5K7IVRnCW5Iig JXpf66z1uK6L93pFjRsXVlPDaM3FHBlGYoxlBh8M= Message-ID: <2df236317429b1c08fa11982d4e65a6b798bd4c6.camel@tugraz.at> Subject: Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896) From: Martin Uecker To: Kees Cook , Qing Zhao Cc: Siddhesh Poyarekar , Richard Biener , Joseph Myers , Jakub Jelinek , gcc Patches , "isanbard@gmail.com" Date: Thu, 26 Oct 2023 10:15:10 +0200 In-Reply-To: <202310251529.296AB019@keescook> References: <168fea24-844e-4d1a-9361-afb6332b4f11@gotplt.org> <8C548B97-BD81-4EBB-A59C-F7E6E0A3C4F7@oracle.com> <92426898-afa7-47f7-9aab-5f2114eb826a@gotplt.org> <05d65224067ff72124d94b6b5274f14d013b64af.camel@tugraz.at> <2A78AF07-4E87-43DD-9C1B-23A15C43A8E4@oracle.com> <202310251504.6DE743979@keescook> <947881C6-7040-4C73-8A81-0F364D0DF469@oracle.com> <202310251529.296AB019@keescook> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-TUG-Backscatter-control: G/VXY7/6zeyuAY/PU2/0qw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -0.4 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116 X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Am Mittwoch, dem 25.10.2023 um 15:32 -0700 schrieb Kees Cook: > On Wed, Oct 25, 2023 at 10:27:41PM +0000, Qing Zhao wrote: > >=20 > >=20 > > > On Oct 25, 2023, at 6:06 PM, Kees Cook wrote: > > >=20 > > > On Wed, Oct 25, 2023 at 01:27:29PM +0000, Qing Zhao wrote: > > > > A. Add an additional argument, the size parameter, to __bdos,=20 > > > > A.1, during FE; > > > > A.2, during gimplification phase; > > >=20 > > > I just wanted to clarify that this is all just an "internal" detail, > > > yes? > >=20 > > YES! >=20 > Okay, I thought so, but I just wanted to double-check. :) >=20 > > > For example, the Linux kernel can still use __bdos() without knowing > > > the count member ahead of time (otherwise it kind of defeats the purp= ose). > > Don=E2=80=99t quite understand this, could you clarify?=20 >=20 > I was just trying to explain why a chance would be a problem. But it > doesn't matter, so nevermind. :) >=20 > > (Anyway, the bottom line is no change to the user interface, we just di= scuss the internal implementation inside GCC) -:) >=20 > Great! I'll go back to lurking. :) >=20 > Thanks! >=20 While it is about the internal implementation, it would potentially affect the semantics of the attribute: This would work: x->count =3D 10; char *p =3D &x->buf; but not this: char *p =3D &x->buf; x->count =3D 1; p[10] =3D 1; // ! (because the pointer is passed around the store to the counter) and also here the second store is then irrelevant for the access: x->count =3D 10; char* p =3D &x->buf; ... x->count =3D 1; // somewhere else ---- p[9] =3D 1; // ok, because count matter when buf was accesssed. IMHO this makes sense also from the user side and are the desirable semantics we discussed before. But can you take a look at this? This should simulate it fairly well: https://godbolt.org/z/xq89aM7Gr (the call to the noinline function would go away, but not necessarily its impact on optimization) Martin