From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id 153343858D37 for ; Thu, 26 Oct 2023 14:06:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 153343858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 153343858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::636 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698329167; cv=none; b=g9tV7QBa4FXXcLe2YnP0SHVKCfM8M+nYeagE6Wdcdryof04BW1solQvCEPtTwWcjb455qaAVUdqu5SeGqb6zzWTL6R8yJyWzwkBjpiagE7Bvb6cN8eejNSqp4G+JMmaXayABZSB2PkS6a0UTtGslgqQlaQx5dXiZPyE2c1GFvZw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698329167; c=relaxed/simple; bh=AnsE06ZmcQ2bN1BwgvNS8y0HrVZl6e3R2+b+yIiwdGM=; h=DKIM-Signature:From:Mime-Version:Subject:Date:Message-Id:To; b=MAkFWVFUoRbmMHwHWZnKXpVYQh43hUgKK+vPy7PBruskTtpv6dcKFZ16Z6nEIYftTnyskJODakSmc82C5HF1roL472Rpq7sb+lj07TOsG/JkyT8R32Ur3jWU+c0GfhSxIadVstEWdZjc7MgO9wrbdZ2VKoRuCYs0neDWXCs3tXo= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-9c603e235d1so161298266b.3 for ; Thu, 26 Oct 2023 07:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698329163; x=1698933963; darn=gcc.gnu.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=zkyZzJiviiMFLfVRtAs7no9ZNryyjphF679jWHEmfkk=; b=XfGg+7OU4ZEGCSHQg6K1lbq/6cHJwRpo7DlfyI9pYStVke4XtR/6dVQzOuJQqel0vX C6qn8TIbdGJCuCHFttA1yl5Yrhl7tquZKElQjI86EiV0RWVlu55SIPawPoaAUaBnWqbi /m3z3+TukURLTD2R5ID9NGaEJrwG52mMpegbfhdLc66a4GZlDaBg3D9YiW8CfxuVDio9 EQVPwsN003uE7YJnR4EznQQUqmUsdnT9/kMu+5Cd7HM6kguXDNit+RriyzOoK7MXTkLm QCFlUox150FDEoLW5klcOyhcBcDLO7c6safcs7oSnjQYXdnbxblholzJZ95PRWyzbCwS IO1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698329163; x=1698933963; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=zkyZzJiviiMFLfVRtAs7no9ZNryyjphF679jWHEmfkk=; b=NtUgmiE9boY+xVZ34yXIk/hIwO20hnTm0GXhYkg43Fx/PAx0bNr8Pouu9vhQjnFqm8 FVX7bvZ8nDownNXxmBHwZ0bLNpSUwZhKYripatNCSweNkVyq59YiRwDofUfQw5souLtC MtilYjwJfjht/Ph9uVfe0UDAwrIXYmhMQKaUfBjH7thuAXLLvwX0Ov4qtH6StaqDIhQy 1jL60xwe1a1wVJHVq6lomjDZpywVFYk/jG/uU9CfjU5VTndquPbAg/PkyDD5vYe0mPwZ MXigfCeQqcPpBsDyqft8p+ln+oLFJN5bd/52HMpiBsRhcQm+VZxQlelwpTZS9mQGcFyx kLuA== X-Gm-Message-State: AOJu0Yzx7kkXrGZ+XHOHOOcmRbWbXJSplb1JJgeY1Dp2RN4K99q17NHh Q4sFpa6qG1fxWh/wayJBRW8= X-Google-Smtp-Source: AGHT+IGruE9BQQW5Okw4jcHb5Tg/XZVW1f+gxTWbzoMnP38vF4RrdU4CahK1U0d3cHoETEmuNTq2Pw== X-Received: by 2002:a17:906:fd82:b0:9b2:7367:a6a4 with SMTP id xa2-20020a170906fd8200b009b27367a6a4mr15948307ejb.31.1698329163360; Thu, 26 Oct 2023 07:06:03 -0700 (PDT) Received: from smtpclient.apple (dynamic-077-007-027-039.77.7.pool.telefonica.de. [77.7.27.39]) by smtp.gmail.com with ESMTPSA id o1-20020a170906774100b009c6e58437dasm11762708ejn.37.2023.10.26.07.06.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Oct 2023 07:06:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Richard Biener Mime-Version: 1.0 (1.0) Subject: Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896) Date: Thu, 26 Oct 2023 16:05:52 +0200 Message-Id: <7C0598D0-DC8E-4E3A-A12E-328B94FC7489@gmail.com> References: <3e9138ad2148f56b504a19253b0518bbd12b9f8c.camel@tugraz.at> Cc: Siddhesh Poyarekar , Qing Zhao , Joseph Myers , Jakub Jelinek , gcc Patches , kees Cook , isanbard@gmail.com In-Reply-To: <3e9138ad2148f56b504a19253b0518bbd12b9f8c.camel@tugraz.at> To: Martin Uecker X-Mailer: iPhone Mail (20H115) X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no 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 26.10.2023 um 12:14 schrieb Martin Uecker : >=20 > =EF=BB=BFAm Donnerstag, dem 26.10.2023 um 11:20 +0200 schrieb Martin Uecke= r: >>> Am Donnerstag, dem 26.10.2023 um 10:45 +0200 schrieb Richard Biener: >>> On Wed, Oct 25, 2023 at 8:16=E2=80=AFPM Martin Uecker = wrote: >>>>=20 >>>> Am Mittwoch, dem 25.10.2023 um 13:13 +0200 schrieb Richard Biener: >>>>>=20 >>>>>> Am 25.10.2023 um 12:47 schrieb Martin Uecker : >>>>>>=20 >>>>>> =EF=BB=BFAm Mittwoch, dem 25.10.2023 um 06:25 -0400 schrieb Siddhesh P= oyarekar: >>>>>>>> On 2023-10-25 04:16, Martin Uecker wrote: >>>>>>>> Am Mittwoch, dem 25.10.2023 um 08:43 +0200 schrieb Richard Biener: >>>>>>>>>=20 >>>>>>>>>> Am 24.10.2023 um 22:38 schrieb Martin Uecker : >>>>>>>>>>=20 >>>>>>>>>> =EF=BB=BFAm Dienstag, dem 24.10.2023 um 20:30 +0000 schrieb Qing Z= hao: >>>>>>>>>>> Hi, Sid, >>>>>>>>>>>=20 >>>>>>>>>>> Really appreciate for your example and detailed explanation. Ver= y helpful. >>>>>>>>>>> I think that this example is an excellent example to show (almos= t) all the issues we need to consider. >>>>>>>>>>>=20 >>>>>>>>>>> I slightly modified this example to make it to be compilable and= run-able, as following: >>>>>>>>>>> (but I still cannot make the incorrect reordering or DSE happeni= ng, anyway, the potential reordering possibility is there=E2=80=A6) >>>>>>>>>>>=20 >>>>>>>>>>> 1 #include >>>>>>>>>>> 2 struct A >>>>>>>>>>> 3 { >>>>>>>>>>> 4 size_t size; >>>>>>>>>>> 5 char buf[] __attribute__((counted_by(size))); >>>>>>>>>>> 6 }; >>>>>>>>>>> 7 >>>>>>>>>>> 8 static size_t >>>>>>>>>>> 9 get_size_from (void *ptr) >>>>>>>>>>> 10 { >>>>>>>>>>> 11 return __builtin_dynamic_object_size (ptr, 1); >>>>>>>>>>> 12 } >>>>>>>>>>> 13 >>>>>>>>>>> 14 void >>>>>>>>>>> 15 foo (size_t sz) >>>>>>>>>>> 16 { >>>>>>>>>>> 17 struct A *obj =3D __builtin_malloc (sizeof(struct A) + sz * s= izeof(char)); >>>>>>>>>>> 18 obj->size =3D sz; >>>>>>>>>>> 19 obj->buf[0] =3D 2; >>>>>>>>>>> 20 __builtin_printf (=E2=80=9C%d\n", get_size_from (obj->buf));= >>>>>>>>>>> 21 return; >>>>>>>>>>> 22 } >>>>>>>>>>> 23 >>>>>>>>>>> 24 int main () >>>>>>>>>>> 25 { >>>>>>>>>>> 26 foo (20); >>>>>>>>>>> 27 return 0; >>>>>>>>>>> 28 } >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>>>> When it=E2=80=99s set I suppose. Turn >>>>>>>>>=20 >>>>>>>>> X.l =3D n; >>>>>>>>>=20 >>>>>>>>> Into >>>>>>>>>=20 >>>>>>>>> X.l =3D __builtin_with_size (x.buf, n); >>>>>>>>=20 >>>>>>>> It would turn >>>>>>>>=20 >>>>>>>> some_variable =3D (&) x.buf >>>>>>>>=20 >>>>>>>> into >>>>>>>>=20 >>>>>>>> some_variable =3D __builtin_with_size ( (&) x.buf. x.len) >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> So the later access to x.buf and not the initialization >>>>>>>> of a member of the struct (which is too early). >>>>>>>>=20 >>>>>>>=20 >>>>>>> Hmm, so with Qing's example above, are you suggesting the transforma= tion >>>>>>> be to foo like so: >>>>>>>=20 >>>>>>> 14 void >>>>>>> 15 foo (size_t sz) >>>>>>> 16 { >>>>>>> 16.5 void * _1; >>>>>>> 17 struct A *obj =3D __builtin_malloc (sizeof(struct A) + sz * size= of(char)); >>>>>>> 18 obj->size =3D sz; >>>>>>> 19 obj->buf[0] =3D 2; >>>>>>> 19.5 _1 =3D __builtin_with_size (obj->buf, obj->size); >>>>>>> 20 __builtin_printf (=E2=80=9C%d\n", get_size_from (_1)); >>>>>>> 21 return; >>>>>>> 22 } >>>>>>>=20 >>>>>>> If yes then this could indeed work. I think I got thrown off by the= >>>>>>> reference to __bdos. >>>>>>=20 >>>>>> Yes. I think it is important not to evaluate the size at the >>>>>> access to buf and not the allocation, because the point is to >>>>>> recover it from the size member even when the compiler can't >>>>>> see the original allocation. >>>>>=20 >>>>> But if the access is through a pointer without the attribute visible >>>>> even the Frontend cannot recover? >>>>=20 >>>> Yes, if the access is using a struct-with-FAM without the attribute >>>> the FE would not be insert the builtin. BDOS could potentially >>>> still see the original allocation but if it doesn't, then there is >>>> no information. >>>>=20 >>>>> We=E2=80=99d need to force type correctness and give up on indirecting= >>>>> through an int * when it can refer to two diffenent container types. >>>>> The best we can do I think is mark allocation sites and hope for >>>>> some basic code hygiene (not clobbering size or array pointer >>>>> through pointers without the appropriately attributed type) >>>>=20 >>>> I am do not fully understand what you are referring to. >>>=20 >>> struct A { int n; int data[n]; }; >>> struct B { long n; int data[n]; }; >>>=20 >>> int *p =3D flag ? a->data : b->data; >>>=20 >>> access *p; >>>=20 >>> Since we need to allow interoperability of pointers (a->data is >>> convertible to a non-fat pointer of type int *) this leaves us with >>> ambiguity we need to conservatively handle to avoid false positives. >>=20 >> For BDOS, I would expect this to work exactly like: >>=20 >> char aa[n1]; >> char bb[n2]; >> char *p =3D flag ? aa : bb; >>=20 >> (or similar code with malloc). In fact it does: >>=20 >> https://godbolt.org/z/bK68YKqhe >> (cheating a bit and also the sub-object version of >> BDOS does not seem to work) >>=20 >>>=20 >>> We _might_ want to diagnose decay of a->data to int *, but IIRC >>> there's no way (or proposal) to allow declaring a corresponding >>> fat pointer, so it's not a good designed feature. >>=20 >> As a language feature, I fully agree. I see the >> counted_by attribute has a makeshift solution. >>=20 >> But we can already do: >>=20 >> auto p =3D flag ? &aa : &bb; >>=20 >> and this already works perfectly: >>=20 >> https://godbolt.org/z/rvb6xWWPj >>=20 >> We can also name the variably-modifed type:=20 >>=20 >> char (*p)[flag ? n1 : n2] =3D flag ? &aa : &bb; >> https://godbolt.org/z/13cTT1vGP >>=20 >> The problem with this version is that consistency >> is not checked. (I have patch for adding run-time >> checks). >>=20 >> And then the next step would be to allow >>=20 >> char (*p)[:] =3D flag ? &aa : &bb; >>=20 >> or similar. Dennis Ritchie proposed this himself >> a long time ago. >>=20 >> So far this seems straightfoward. >>=20 >> If we then want to allow such wide pointers as >> function arguments or in structs, we would need >> to define an ABI. But the ABI could just be >>=20 >> struct { char (*p)[.s]; size_t s; }; >>=20 >> Maybe we could try to make the following >> ABI compatible: >>=20 >> int foo(int p[s], size_t s); >> int foo(int p[:]); >>=20 >>=20 >>> Having __builtin_with_size at allocation would possibly make >>> the BOS use-def walk discover both objects. >>=20 >> Yes. But I do not think this there is any fundamental >> difference to discovering allocation functions. >>=20 >>> I think you can't >>> insert __builtin_with_size at the access to *p, but in practice >>> that would be very much needed. >>=20 >> Usually the access to *p would follow directly the >> access x.buf, so BDOS should find it. >>=20 >> But yes, to get full bounds safety, the pointer type=20 >> has to change to a variably-modified type (which would work >> today) or a fat pointer type. The later can be built on >> vm-types easily because all the FE semantics already >> exists. >=20 > We could insert the __builtin_with_size everywhere > we have to convert a wide pointer or let an array > decay to traditional pointer for reason of compatibility=20 > with legacy code. That sounds like a nice idea. Note I=E2=80=99d like to see the consumer sid= e implemented so we can play with different points of insertion (and I=E2=80= =99ll try to show corner cases where it goes wrong). It all seems a bit lat= e for GCC 14 though. Richard=20 > Martin >=20 >>=20 >> Martin >>=20 >>>=20 >>> Richard. >>>=20 >>>> But yes, >>>> for full bounds safety we would need the language feature. >>>> In C people should start to variably-modified types >>>> more. I think we can build perfect bounds safety on top of >>>> them in a very good way with only FE changes. >>>>=20 >>>> All these attributes are just a best effort. But for a while, >>>> this will be necessary. >>>>=20 >>>> Martin >>>>=20 >>>>>=20 >>>>>> Evaluating at this point requires that the size is correctly set >>>>>> before the access to the FAM and the user has to make sure >>>>>> this is the case. But to me this requirement would make sense. >>>>>>=20 >>>>>> Semantically, it could a=C3=B6so make sense to evaluate the size at a= >>>>>> later time. But then the reordering becomes problematic again. >>>>>>=20 >>>>>> Also I think this would make this feature generally more useful. >>>>>> For example, it could work also for others pointers in the struct >>>>>> and not just for FAMs. In this case, the struct may already be >>>>>> freed when BDOS is called, so it might also not possible to >>>>>> access the size member at a later time. >>>>>>=20 >>>>>> Martin >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>=20 >>=20 >=20