svn commit: r313166 - head/sys/boot/efi/libefi

Ian Lepore ian at freebsd.org
Fri Feb 3 20:44:59 UTC 2017


On Fri, 2017-02-03 at 13:25 -0700, Warner Losh wrote:
> On Fri, Feb 3, 2017 at 11:20 AM, Ian Lepore <ian at 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 at 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).

-- Ian



More information about the svn-src-head mailing list