From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11404 invoked by alias); 9 Jan 2020 22:23:01 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 11389 invoked by uid 89); 9 Jan 2020 22:23:01 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail.efficios.com Received: from mail.efficios.com (HELO mail.efficios.com) (167.114.142.138) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 09 Jan 2020 22:23:00 +0000 Received: from localhost (ip6-localhost [IPv6:::1]) by mail.efficios.com (Postfix) with ESMTP id 847A069690E; Thu, 9 Jan 2020 17:22:58 -0500 (EST) Received: from mail.efficios.com ([IPv6:::1]) by localhost (mail02.efficios.com [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id g-11DLJTg0Td; Thu, 9 Jan 2020 17:22:58 -0500 (EST) Received: from localhost (ip6-localhost [IPv6:::1]) by mail.efficios.com (Postfix) with ESMTP id 2234E69690A; Thu, 9 Jan 2020 17:22:58 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 2234E69690A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1578608578; bh=RQ3fV45bQ60AcKO1wxEFXuEj63AwWHk5jlQpFyQV7Dk=; h=To:From:Message-ID:Date:MIME-Version; b=XT0+fIGDf68eUh/DrRTzm6t9/w9Wg3Y8TnAd10sUvbrO9vliHBm57J3BSCEQh41x5 JtXS0tXZqS9r2Cwfmiz1JbqO3vkDbub6kX3H5lMJPotWmLDy/P75YzX36R2wM3GKmC 8e5EVIZOIPnUsORPa7nY8OggdzF9aZQibtNEFOuJJyEY3wUtBQppaHz707tq3iHt/J EOFA2hV4GMJnYm+Hmz7ayRwrUOcKqfIi9NdJdg8yW8mBJ8Dn0MWdcgopHWWnH5Np+r Lx+LE800tk88AbOocJ2h7/JJWQbw4i3DsaoYZpGboEQScaRqDIibU7tvy9y2/epguS tD169JRcBGveA== Received: from mail.efficios.com ([IPv6:::1]) by localhost (mail02.efficios.com [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id EL7ttgCdvgMH; Thu, 9 Jan 2020 17:22:58 -0500 (EST) Received: from [172.16.0.95] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) by mail.efficios.com (Postfix) with ESMTPSA id 03302696900; Thu, 9 Jan 2020 17:22:57 -0500 (EST) Subject: Re: [PATCH 01/15] Add back declarations for _initialize functions To: John Baldwin , gdb-patches@sourceware.org References: <20191125052655.22696-1-simon.marchi@efficios.com> <20191125052655.22696-2-simon.marchi@efficios.com> From: Simon Marchi Message-ID: Date: Thu, 09 Jan 2020 22:23:00 -0000 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 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2020-01/txt/msg00222.txt.bz2 On 2020-01-09 1:46 p.m., John Baldwin wrote: > On 11/24/19 9:26 PM, Simon Marchi wrote: >> I'd like to enable the -Wmissing-declarations warning. However, it >> warns for every _initialize function, for example: >> >> CXX dcache.o >> /home/smarchi/src/binutils-gdb/gdb/dcache.c: In function =E2=80=98vo= id _initialize_dcache()=E2=80=99: >> /home/smarchi/src/binutils-gdb/gdb/dcache.c:688:1: error: no previou= s declaration for =E2=80=98void _initialize_dcache()=E2=80=99 [-Werror=3Dmi= ssing-declarations] >> _initialize_dcache (void) >> ^~~~~~~~~~~~~~~~~~ >> >> The only practical way forward I found is to add back the declarations, >> which were removed by this commit: >> >> commit 481695ed5f6e0a8a9c9c50bfac1cdd2b3151e6c9 >> Author: John Baldwin >> Date: Sat Sep 9 11:02:37 2017 -0700 >> >> Remove unnecessary function prototypes. >> >> I don't think it's a big problem to have the declarations for these >> functions, but if anybody has a better solution for this, I'll be happy >> to use it. >=20 > (Sorry for the late reply, but I don't think I've seen this pushed in yet= ?) >=20 > I don't have a better solution. I feel like clang warned about the > declarations perhaps, but I can't find the reason for making this change > in the old branch. It might be worth testing a build with clang to see > if this adds new warnings there or not. I can help with doing that if ne= eded. > If it does trigger a warning on clang we might also just choose to mute t= hat > warning (I think since the original commit we have added the ability to h= ave > clang- and gcc-specific warning flags). Thanks for bringing this up, I have forgotten to follow up on it. As Tom noted on patch 15, gdbserver also uses warning.m4, and I had forgotten to run autoconf on it. And of course, it revealed more spots that would need fixing. And among those, the functions used both in the in-process agent and in gdbserver itself are problematic, because they should be exported wh= en built for the IPA, but static when built for gdbserver. So I gave up on it for the moment. This patch (01/15) would only be relevant if the rest goes= in too, but I note your comment about clang. Thanks, Simon