From owner-svn-src-head@freebsd.org Fri Jul 21 06:15:59 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AFEB8D96944; Fri, 21 Jul 2017 06:15:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5666564F45; Fri, 21 Jul 2017 06:15:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v6L6Fr4N007675 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 21 Jul 2017 09:15:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v6L6Fr4N007675 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v6L6Fqvm007671; Fri, 21 Jul 2017 09:15:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 21 Jul 2017 09:15:52 +0300 From: Konstantin Belousov To: Ryan Libby Cc: Bruce Evans , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, imp@freebsd.org Subject: Re: svn commit: r321284 - in head/sys: amd64/include sys Message-ID: <20170721061552.GK1935@kib.kiev.ua> References: <201707200647.v6K6l7Hq076554@repo.freebsd.org> <20170720172157.W1152@besplex.bde.org> <20170720103323.GG1935@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 06:15:59 -0000 On Thu, Jul 20, 2017 at 04:02:02PM -0700, Ryan Libby wrote: > On Thu, Jul 20, 2017 at 3:33 AM, Konstantin Belousov > wrote: > > On Thu, Jul 20, 2017 at 02:08:30AM -0700, Ryan Libby wrote: > >> On Thu, Jul 20, 2017 at 1:01 AM, Bruce Evans wrote: > [...] > >> > This bug is not very common. There seem to be no instances of it in > >> > (only sys/cdefs.h uses __attribute__(()), and it seems to use > >> > underscores for all the attributes). Grepping sys/include/*.h for > >> > attribute shows the following bugs: > >> > > >> > X amd64/include/efi.h:#define EFIABI_ATTR __attribute__((ms_abi)) > >> > X i386/include/efi.h:#define EFIABI_ATTR /* __attribute__((ms_abi)) */ /* clang fails with this */ > >> > X ofed/include/rdma/ib_user_mad.h:typedef unsigned long __attribute__((aligned(4))) packed_ulong; > >> > X ofed/include/rdma/ib_smi.h:} __attribute__ ((packed)); > >> > X ofed/include/rdma/ib_mad.h:} __attribute__ ((packed)); > >> > X ofed/include/rdma/ib_mad.h:} __attribute__ ((packed)); > >> > > >> > The commented-out ms_abi was only a style bug. Now it is a larger style > >> > bug -- it is different and worse than amd64. > >> > >> I'm not sure what to do about i386 there (again beyond fixing up the > >> spelling in the comment). Maybe the unsupported architectures should > >> just not be declaring EFIABI_ATTR at all? (Thoughts, kib?) > > > > I think i386 should be treated exactly same as amd64, i.e. EFIABI_ATTR > > should be not defined if gcc < 4.4. Or I do not understand the scope > > of the question. > > After googling around [1] and a quick check of the spec [2], it now > seems to me that the i386 comment might just be erroneous. I think the > right solution for sys/i386/include/efi.h may just be to delete the > comment and leave that EFIAPI_ATTR macro definition as empty (always, no > compiler version check) in order to use the native calling convention. > > [1] http://wiki.osdev.org/UEFI#Calling_Conventions > [2] http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf At very least, the UEFI Spec requires 16-byte alignment of the stack. This is not guaranteed by our i386 ABI.