Date: Fri, 3 Feb 2017 13:48:55 -0700 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@freebsd.org> Cc: Toomas Soome <tsoome@me.com>, Toomas Soome <tsoome@freebsd.org>, src-committers <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r313166 - head/sys/boot/efi/libefi Message-ID: <CANCZdfoyTbFXnxqWWYJicUXQgMdNdUgm8r-7YoD0CPcvFoTZ3A@mail.gmail.com> In-Reply-To: <1486154696.3017.201.camel@freebsd.org> 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> <CANCZdfrnjSNf%2BNmo0q3U=hMua7tJ32goOHUDu7JkjVFHbx_m5A@mail.gmail.com> <1486154696.3017.201.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 3, 2017 at 1:44 PM, Ian Lepore <ian@freebsd.org> wrote: > On Fri, 2017-02-03 at 13:25 -0700, Warner Losh wrote: >> On Fri, Feb 3, 2017 at 11:20 AM, Ian Lepore <ian@freebsd.org> wrote: >> > >> > On Fri, 2017-02-03 at 18:52 +0200, Toomas Soome wrote: >> > > >> > > > >> > > > >> > > > On 3. veebr 2017, at 18:47, Ian Lepore <ian@freebsd.org> 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). Gotcha. I know the linker records various details in the .o's for sanity checking. Didn't think this was one of them, so, yea, it looks like you're right. We may have to build a separate copy of such libraries for UEFI since it has a different ABI. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoyTbFXnxqWWYJicUXQgMdNdUgm8r-7YoD0CPcvFoTZ3A>