From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 2CB853857405 for ; Tue, 21 Jun 2022 20:31:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2CB853857405 Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-462-EW3AvlxkM0aPhiLmhNQDyQ-1; Tue, 21 Jun 2022 16:31:46 -0400 X-MC-Unique: EW3AvlxkM0aPhiLmhNQDyQ-1 Received: by mail-qv1-f69.google.com with SMTP id jo22-20020a056214501600b004646309a886so15431665qvb.2 for ; Tue, 21 Jun 2022 13:31:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=cJWxMyvS+EBYXpjk6HC9+kKOO7NIU3gHtIvFu83JlGc=; b=Dw95HI008HYAhEjKQQMKmeEp6CHNDvNVe3aPxXgbFGzRyVMfNng1fzz7DEi4lrrByU iaDgjAQpxcmuDwdOsJXURRHAi5gYB/XduCrA5XDGUNseTd6SKYva8DhqoqZHz2xmm1gu F2z2OWf/Kb+HiHwLYgSeK7432ydKDozPsZ41lcQ2L/Xpv26w7jfp3NK3HWxsSib1tojo eGg4bcffbkOwJjXctm48wnpkC/dnlX7oDq7EdikHGvCJEypXPw/xJ9IRlSyujXE66K8i Vj1uqqo6ogrD98goQr7cwv0be6Ps8ADyle6KX8wlOZI6Za6xPCtiag1x+AGNBJdnmiVC 889g== X-Gm-Message-State: AJIora+T9WhP5GZREVwAUM67+b2mjZAZ61YzJeJKH5YznjaLa/D6TYuw JWq56b3KT27nVorYFff4jRU9ZgMaNDU2jLpNIOke19oTnt7aMWCPCPys462BZ5BchJQuElUiMjk Nf+1VfMw= X-Received: by 2002:ac8:5f85:0:b0:315:58a2:ec86 with SMTP id j5-20020ac85f85000000b0031558a2ec86mr26110qta.333.1655843506331; Tue, 21 Jun 2022 13:31:46 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vQlhL8LjsU1kfUsJ39OlB8UYzhV26ObQ6MfR5tMIV7urD2RuYEn6aqgKevBHoRD7KZiis/Mw== X-Received: by 2002:ac8:5f85:0:b0:315:58a2:ec86 with SMTP id j5-20020ac85f85000000b0031558a2ec86mr26092qta.333.1655843506082; Tue, 21 Jun 2022 13:31:46 -0700 (PDT) Received: from t14s.localdomain (c-73-69-212-193.hsd1.nh.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id v11-20020a05620a440b00b006a6a7b4e7besm16138431qkp.109.2022.06.21.13.31.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Jun 2022 13:31:45 -0700 (PDT) Message-ID: <78c6ac309f6c30e003e32481bce55aebe34ef488.camel@redhat.com> Subject: Re: [PATCH] static analysis support for posix file desccriptor APIs From: David Malcolm To: Joseph Myers Cc: Mir Immad , gcc@gcc.gnu.org Date: Tue, 21 Jun 2022 16:31:44 -0400 In-Reply-To: References: User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2022 20:31:50 -0000 On Tue, 2022-06-21 at 18:50 +0000, Joseph Myers wrote: > On Tue, 21 Jun 2022, David Malcolm via Gcc wrote: > > > So ultimately that's something we want to fix, though exactly how, > > I'm > > not quite sure; we presumably want to look up the target's > > definitions > > of those macros - but I don't think the analyzer has access to the > > cpp_reader instance from the frontend. > > Normally that would use a target hook to specify the values of those > macros.  The default would be the traditional Unix values of 0, 1, 2 > for > O_RDONLY, O_WRONLY, O_RDWR, while Hurd would need its own definition of > the hook to use values 1, 2, 3 (I don't know if there are any non-Hurd > systems not using the traditional values). I found that it's at least theoretically possible to access the preprocessor from within the analyzer; e.g. given: #define O_RDONLY 42 and then breaking in the debugger in ana::run_checkers: (gdb) p cpp_lookup (parse_in, (unsigned char *)"O_RDONLY", (size_t)strlen ("O_RDONLY")) $1 = (cpp_hashnode *) 0x7fffea794248 (gdb) p *$1 $2 = {ident = {str = 0x7fffea7877d0 "O_RDONLY", len = 8, hash_value = 3761648590}, is_directive = 0, directive_index = 0, rid_code = 0, flags = 0, type = NT_USER_MACRO, deferred = 0, value = {answers = 0x7fffea7a5480, macro = 0x7fffea7a5480, builtin = 3933885568, arg_index = 21632}} (gdb) p $1->value.macro.exp.tokens.type $6 = CPP_NUMBER (gdb) p $1->value.macro.exp.tokens.val.str $7 = {len = 2, text = 0x3ec182b "42"} so given the C/C++ FEs it might be possible for the analyzer to try to lookup the value of O_RDONLY. But I'm wary of this; e.g. the LTO case, and for non-trivial macro definitions. Joseph: is the target hook the way to go with this? Would it look something like: DEFHOOK (fd_access_mode, "FIXME", int (int)) taking the build configuration's O_ access mode, and returning the target configurations's access mode (so e.g fd_access_mode (O_RDONLY) would return the target's int) ? Thanks Dave