| Message ID | 16541778.WMH6K24aDt@wuerfel (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
>>> On 11.08.16 at 14:39, <arnd@arndb.de> wrote: > A previous patch added the --no-wchar-size-warning to the Makefile to > avoid this harmless warning: > > arm-linux-gnueabi-ld: warning: drivers/xen/efi.o uses 2-byte wchar_t yet the > output is to use 4-byte wchar_t; use of wchar_t values across objects may > fail > > Changing kbuild to use thin archives instead of recursive linking > unfortunately brings the same warning back during the final link. > > This time, we remove the -fshort-wchar flag that originally caused > the warning, hopefully fixing the problem for good. I don't see > any reason for having the flag in the first place, as the Xen code > does not use wchar_t at all. It uses efi_char16_t, and by dropping -fshort-wchar you'd open up a trap for anyone to fall into who were to add wide string literals to that same file. EFI using 16-bit characters requires code interfacing with EFI to do so too. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday, August 11, 2016 6:51:33 AM CEST Jan Beulich wrote: > >>> On 11.08.16 at 14:39, <arnd@arndb.de> wrote: > > A previous patch added the --no-wchar-size-warning to the Makefile to > > avoid this harmless warning: > > > > arm-linux-gnueabi-ld: warning: drivers/xen/efi.o uses 2-byte wchar_t yet the > > output is to use 4-byte wchar_t; use of wchar_t values across objects may > > fail > > > > Changing kbuild to use thin archives instead of recursive linking > > unfortunately brings the same warning back during the final link. > > > > This time, we remove the -fshort-wchar flag that originally caused > > the warning, hopefully fixing the problem for good. I don't see > > any reason for having the flag in the first place, as the Xen code > > does not use wchar_t at all. > > It uses efi_char16_t, and by dropping -fshort-wchar you'd open > up a trap for anyone to fall into who were to add wide string > literals to that same file. EFI using 16-bit characters requires > code interfacing with EFI to do so too. I don't understand. How is this different from other source files that use efi_char16_t or the wchar_t definition from include/linux/nls.h? As far as I can tell, they all use 16-bit characters, but none of the others sets the flag. Maybe we should just always build with -fshort-wchar from the top-level Makefile? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> On 11.08.16 at 16:01, <arnd@arndb.de> wrote: > On Thursday, August 11, 2016 6:51:33 AM CEST Jan Beulich wrote: >> >>> On 11.08.16 at 14:39, <arnd@arndb.de> wrote: >> > A previous patch added the --no-wchar-size-warning to the Makefile to >> > avoid this harmless warning: >> > >> > arm-linux-gnueabi-ld: warning: drivers/xen/efi.o uses 2-byte wchar_t yet the >> > output is to use 4-byte wchar_t; use of wchar_t values across objects may >> > fail >> > >> > Changing kbuild to use thin archives instead of recursive linking >> > unfortunately brings the same warning back during the final link. >> > >> > This time, we remove the -fshort-wchar flag that originally caused >> > the warning, hopefully fixing the problem for good. I don't see >> > any reason for having the flag in the first place, as the Xen code >> > does not use wchar_t at all. >> >> It uses efi_char16_t, and by dropping -fshort-wchar you'd open >> up a trap for anyone to fall into who were to add wide string >> literals to that same file. EFI using 16-bit characters requires >> code interfacing with EFI to do so too. > > I don't understand. How is this different from other source files > that use efi_char16_t or the wchar_t definition from include/linux/nls.h? Perhaps they didn't run into the issue yet? > As far as I can tell, they all use 16-bit characters, but none of the > others sets the flag. Maybe we should just always build with -fshort-wchar > from the top-level Makefile? Quite possible, unless elsewhere in the tree 4-byte characters are needed. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/08/16 13:39, Arnd Bergmann wrote: > A previous patch added the --no-wchar-size-warning to the Makefile to > avoid this harmless warning: > > arm-linux-gnueabi-ld: warning: drivers/xen/efi.o uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail > > Changing kbuild to use thin archives instead of recursive linking > unfortunately brings the same warning back during the final link. > > This time, we remove the -fshort-wchar flag that originally caused > the warning, hopefully fixing the problem for good. I don't see > any reason for having the flag in the first place, as the Xen code > does not use wchar_t at all. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > Fixes: 971a69db7dc0 ("Xen: don't warn about 2-byte wchar_t in efi") Acked-by: David Vrabel <david.vrabel@citrix.com> David -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile index 8feab810aed9..7f188b8d0c67 100644 --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@ -7,9 +7,6 @@ obj-y += xenbus/ nostackp := $(call cc-option, -fno-stack-protector) CFLAGS_features.o := $(nostackp) -CFLAGS_efi.o += -fshort-wchar -LDFLAGS += $(call ld-option, --no-wchar-size-warning) - dom0-$(CONFIG_ARM64) += arm-device.o dom0-$(CONFIG_PCI) += pci.o dom0-$(CONFIG_USB_SUPPORT) += dbgp.o