From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc2a.google.com (mail-oo1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) by sourceware.org (Postfix) with ESMTPS id E74CB3857820 for ; Wed, 13 Oct 2021 17:03:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E74CB3857820 Received: by mail-oo1-xc2a.google.com with SMTP id i1-20020a4ab241000000b002b7069d0e88so1005469ooo.5 for ; Wed, 13 Oct 2021 10:03:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=spqIsBPMKOUtdPcWLcBiV34eQAZgZfw/hDEBtz+DCpQ=; b=z5RSvJZSid1QnvL+AyflXDdg8CNs1JgK29GAUS5wShJ/xG9QNUanyzygGrEUwl6v2h Wh5gTJGtav2lF+KA1AxMmwm3OaVRkiRrLX8AyOU/liGUZwszLLodHgR5nyP0gQa+Y09C Vl1ZU4Z/hMS2LxgvsBiY37LpCJ0HEZEObpob/rbF7xSddPnE82VDPR3KURGnLKR1RnX8 lYVkmDi5KsJpzmEcPjt5ju4TkCuU/7QWkVjoQLKKSOpnFa/+obPXd7uP8p02kEapFyUU o3yFXIhkd2pAqF9+punmLnmJUVD52TCorXaSUoxRvdh0jjN3pwph3nBVmYKxuxazMi8Q Wu2Q== X-Gm-Message-State: AOAM530Q+GHVN/6m0th9KqbTCoaQqE1sJgBZMuJzTTpTz0sjQHSqso4c gGcQE+dx3xP4uOgDV+t6TGaLWPCMNf0= X-Google-Smtp-Source: ABdhPJwFh/XiS6T6qTiIlEoCKikrdLOaA58mJnRXxJeEwDkvlRJg9ptWlyL6Wwktg9O95bIahsJ3tg== X-Received: by 2002:a05:6820:1504:: with SMTP id ay4mr235722oob.34.1634144620114; Wed, 13 Oct 2021 10:03:40 -0700 (PDT) Received: from [192.168.0.41] (184-96-250-116.hlrn.qwest.net. [184.96.250.116]) by smtp.gmail.com with ESMTPSA id m13sm34930oou.25.2021.10.13.10.03.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Oct 2021 10:03:39 -0700 (PDT) Subject: Re: [PATCH] check to see if null pointer is dereferenceable [PR102630] To: Richard Biener Cc: Joseph Myers , gcc-patches References: <806cc630-86ef-2e3f-f72b-68bab2cd3e86@gmail.com> From: Martin Sebor Message-ID: <9444daf4-28a3-c618-5328-f3267e0dd92f@gmail.com> Date: Wed, 13 Oct 2021 11:03:38 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 17:03:43 -0000 On 10/13/21 2:25 AM, Richard Biener wrote: > On Wed, Oct 13, 2021 at 3:32 AM Martin Sebor via Gcc-patches > wrote: >> >> On 10/11/21 6:26 PM, Joseph Myers wrote: >>> The testcase uses the __seg_fs address space, which is x86-specific, but >>> it isn't in an x86-specific directory or otherwise restricted to x86 >>> targets; thus, I'd expect it to fail for other architectures. >>> >>> This is not a review of the rest of the patch. >>> >> >> Good point! I thought I might make the test target-independent >> (via macros) but it looks like just i386 defines the hook to >> something other than false so I should probably move it under >> i386. > > The patch is OK with the testcase moved. I changed the test, moved it under the i386 directory, and also added -Wall to the existing addr-space-2.c, and committed the result in r12-4376. > > Note I don't think we should warn about *(int *)0xdeadbee0, > > /* Pointer constants other than null are most likely the result > - of erroneous null pointer addition/subtraction. Set size to > - zero. For null pointers, set size to the maximum for now > - since those may be the result of jump threading. */ > > there's too much "may be" and "most likely" for my taste. How can > the user mark a deliberate valid constant address? Using a volatile pointer works int* volatile p = (int*)0xdeadbee0; *p = 0; but is not very elegant. The other common solution is to make it a variable and assign it an address in a linker script, but that's too heavy-weight for some. I would prefer to make AVR's attribute address generic and encourage programmers to switch to using it to declare these things as objects. The major advantage is that what's at such an address becomes a first class citizen in the type system (and beyond), with a type and size. > > Maybe we can use better (target dependent?) heuristic based on > what virtual addresses are likely unmapped (the zero page, the > page "before" the zero page)? I agree we need something better: ideally, detect the null pointer arithmetic before it's folded into a constant pointer address. I've opened pr102731 as a reminder. Martin > > Richard. > > >> Thanks >> Martin