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.129.124]) by sourceware.org (Postfix) with ESMTPS id DA1963857BBC for ; Wed, 1 Jun 2022 18:50:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DA1963857BBC Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-253-jw0SMR1tOPaS3Z2zAYCORg-1; Wed, 01 Jun 2022 14:50:26 -0400 X-MC-Unique: jw0SMR1tOPaS3Z2zAYCORg-1 Received: by mail-qv1-f72.google.com with SMTP id i15-20020ad45c6f000000b0046462f670d2so1979751qvh.18 for ; Wed, 01 Jun 2022 11:50:26 -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=lOFm9x235J1m9ZBP4AD16l544IUdT2YVoTymIMIc7Ok=; b=FD7k4fzjlu4mPnz4HJL13CQpJxrV1d4siLVRd/SpteOkFQf58pnytOCXjeqOHBhgHu uYABDFQpcjgEukG8nEEWzmp6bw2tv0cwLHsXKYqWeqIc988636WYlMw48P7TtW4AFPSw lTaVwpwJCGXfOPUWm/eFCwPfKrNwBBnIZEHXVKMZDErptKKNR2dgjnFVU6t5VU4uTCoe 9qjceFq0shSr0yXjed9Zd8T4oJbJfGgzZU8kASITNvmFvpRtAIZgLAiQPx2jZ8HjVgwz pKTI2Vfwt/phOgvw/GKUHeQPu/vlduZ6rSPq0DejtEWkIkPAD9pUMidMrXI607X/HEPg EC2Q== X-Gm-Message-State: AOAM532UzkCu12ao4RSswlfAWCY87Ml0jzmCw8G5qR0bPOml25JDrSI2 wmrDDscrHpbV4+rXwDGyNyECZ1yNJrxAw7axWdI9zOoIGFU0s9+h9pL2uIQCbQ/MqWR6zV6eCGf 9gMS8Y/g= X-Received: by 2002:ac8:5c47:0:b0:302:bc9:6001 with SMTP id j7-20020ac85c47000000b003020bc96001mr987268qtj.246.1654109425614; Wed, 01 Jun 2022 11:50:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJywOnS9NEO5HVwt4A9yCbexEiogXUVo3I945si6FXZQ1Z+262+YIzlbv3mEwUV9SwuIoz2HOw== X-Received: by 2002:ac8:5c47:0:b0:302:bc9:6001 with SMTP id j7-20020ac85c47000000b003020bc96001mr987249qtj.246.1654109425255; Wed, 01 Jun 2022 11:50:25 -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 c65-20020a37b344000000b0069fc13ce1e8sm1812284qkf.25.2022.06.01.11.50.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 11:50:24 -0700 (PDT) Message-ID: <69f2466b2bbcf360a027b8deff234dbc99df5348.camel@redhat.com> Subject: Re: GSoC: Getting started From: David Malcolm To: Mir Immad , gcc@gcc.gnu.org Date: Wed, 01 Jun 2022 14:50:22 -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: 7bit X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_NONE, 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: Wed, 01 Jun 2022 18:50:30 -0000 On Wed, 2022-06-01 at 23:22 +0530, Mir Immad wrote: > HI everyone, > > I'm Immad Mir -- one of the GSoC students this year. I'll be working on > adding static analysis support for POSIX file description APIs this > summer. Welcome Immad - I'm looking forward to helping you on this project. For reference, I think you posted an initial prototype of this work earlier this year here: https://gcc.gnu.org/pipermail/gcc/2022-January/238192.html https://gcc.gnu.org/pipermail/gcc/2022-February/238215.html > > The plan is to let the static analyzer know about the FD APIs through > the > use of function attributes, although initially we might hardcode the > logic > to get started working. I'm looking for the suggestions on this from > the > people who have experience working with file-descriptors. We talked about this off-list; I think next steps could be: (1) get your initial prototype working again, hardcoding the names of the functions for simplicity at first (2) find a list of system calls (e.g. those implemented on Linux), and see which ones relate to file descriptors e.g. acquiring them, using them, releasing them, and duplicating them. Look for patterns of usage that could be expressed using function attributes. Probably ignore "ioctl" for now. (3) probably talk to glibc's developers about this, since glibc provides headers that wrap system calls, which would want to use the attributes if we provide them (4) implement the attributes, so that the analyzer doesn't have hardcoded function names, and can instead rely on function attributes. GCC's attributes are implemented in gcc/c-family/c-attribs.cc; see the big c_common_attribute_table array, which associates the string names of the attrbutes with properties, including a handler callback. These either set flags of a decl, or the attribute itself is appended to a singly-linked list on that decl (for those things that don't directly relate to fields of a decl). I believe Siddhesh Poyarekar has been looking at attributes from the glibc side of things, so I'm CCing him in case he has input on this. I'm wondering if other people on this list have ideas for projects that make heavy use of syscalls/file-descriptors that would benefit from having this analyzer feature. Maybe systemd? Welcome again; hope this makes sense and is helpful Dave