From owner-svn-src-head@freebsd.org Fri Feb 3 20:44: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 868E0CCF48A for ; Fri, 3 Feb 2017 20:44:59 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 6800CA6A for ; Fri, 3 Feb 2017 20:44:59 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 9cc4439b-ea51-11e6-b3c2-c9f38144898e X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 9cc4439b-ea51-11e6-b3c2-c9f38144898e; Fri, 03 Feb 2017 20:44:53 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v13KiujP024845; Fri, 3 Feb 2017 13:44:56 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1486154696.3017.201.camel@freebsd.org> Subject: Re: svn commit: r313166 - head/sys/boot/efi/libefi From: Ian Lepore To: Warner Losh Cc: Toomas Soome , Toomas Soome , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Date: Fri, 03 Feb 2017 13:44:56 -0700 In-Reply-To: References: <201702031639.v13GdAXQ074031@repo.freebsd.org> <1486140447.3017.189.camel@freebsd.org> <19994E26-42EE-4E12-9867-1E53FA2A7F81@me.com> <1486146017.3017.193.camel@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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, 03 Feb 2017 20:44:59 -0000 On Fri, 2017-02-03 at 13:25 -0700, Warner Losh wrote: > On Fri, Feb 3, 2017 at 11:20 AM, Ian Lepore wrote: > > > > On Fri, 2017-02-03 at 18:52 +0200, Toomas Soome wrote: > > > > > > > > > > > > > > > On 3. veebr 2017, at 18:47, Ian Lepore wrote: > > > > > > > > On Fri, 2017-02-03 at 16:39 +0000, Toomas Soome wrote: > > > > > > > > > > > > > > > Author: tsoome > > > > > Date: Fri Feb  3 16:39:10 2017 > > > > > New Revision: 313166 > > > > > URL: https://svnweb.freebsd.org/changeset/base/313166 > > > > > > > > > > Log: > > > > >   loader: libefi/env.c warnings in arm build > > > > > > > > > >   The arm build has revealed some of the warnings, the fix > > > > > for > > > > > CHAR16 > > > > >   warning is to switch the warning off for env.c (same as for > > > > > efinet.c). > > > > > > > > > How is disabling the warning instead of just fixing it the > > > > right > > > > thing > > > > to do?  I think disabling a printf format warning is never the > > > > right > > > > thing to do, it just turns a compile warning into a runtime > > > > failure. > > > I would love to see the correct fix - as all UEFI chars are 2 > > > byte; > > > but thats up to arm experts. I just do not know the details why > > > the > > > arm is stuck with 4 byte wchar_t there - Im sure they do not have > > > this just for fun:) > > > > > > rgds, > > > toomas > > Hmm, looks like the right fix is to add -fshort-wchar to CFLAGS, > > but > > it's got to be consistant across all the libraries that get linked, > > and > > some of them are used in the non-efi case too.  I'll have a closer > > look > >  at whether we can fix it properly over the next few days. > I just wonder why that isn't the default.... And the consistency > matters only of wchar_t is used in the library... Lemme know what you > come up with... > > Warner ARM's abi definition requires 4-byte wchar_t, but allows "certain virtual environments" to use different sizes (without any explanation about what that might mean or how to achieve it). I'm not sure about the "only matters if" part -- the linker was spitting out hundreds of warnings about mismatched wchar_t sizes, as if it were part of object file metadata that failed a sanity check or something (or there are a lot more references to wchar_t in libstand and libfdt than I would have imagined). -- Ian