All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Jan Beulich <JBeulich@suse.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	David Vrabel <david.vrabel@citrix.com>,
	Alan Modra <amodra@gmail.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	Segher Boessenkool <segher@kernel.crashing.org>,
	Nicolas Pitre <nico@linaro.org>,
	xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Sam Ravnborg <sam@ravnborg.org>, Juergen Gross <JGross@suse.com>,
	Michal Marek <MMarek@suse.com>,
	linux-arch@vger.kernel.org, linux-kbuild@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] Xen: remove -fshort-wchar gcc flag
Date: Thu, 11 Aug 2016 16:01:40 +0200	[thread overview]
Message-ID: <1924668.nNs2RHZJcd@wuerfel> (raw)
In-Reply-To: <57AC90F5020000780010515A@prv-mh.provo.novell.com>

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

  reply	other threads:[~2016-08-11 14:02 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-11 10:16 [PATCH 0/6 v2] kbuild changes, thin archives, --gc-sections Nicholas Piggin
2016-08-11 10:16 ` [PATCH 1/6] kbuild: allow architectures to use thin archives instead of ld -r Nicholas Piggin
2016-08-11 10:16 ` [PATCH 2/6] kbuild: allow archs to select link dead code/data elimination Nicholas Piggin
2016-08-11 10:16 ` [PATCH 3/6] kbuild: add arch specific post-link pass Nicholas Piggin
2016-08-16  9:23   ` Michal Marek
2016-08-17  4:43     ` Nicholas Piggin
2016-08-17  9:05       ` Michal Marek
2016-08-17  9:56       ` Sam Ravnborg
2016-08-18  0:17         ` Nicholas Piggin
2016-08-11 10:16 ` [PATCH 4/6] powerpc: switch to using thin archives Nicholas Piggin
2016-08-11 10:16 ` [PATCH 5/6] powerpc/64: use linker dead code elimination Nicholas Piggin
2016-08-11 10:16 ` [PATCH 6/6] powerpc: use the new post-link pass to check relocations Nicholas Piggin
2016-08-11 12:31 ` [PATCH 0/6 v2] kbuild changes, thin archives, --gc-sections Stephen Rothwell
2016-08-11 12:39 ` [PATCH] Xen: remove -fshort-wchar gcc flag Arnd Bergmann
2016-08-11 12:51   ` Jan Beulich
2016-08-11 12:51   ` [Xen-devel] " Jan Beulich
2016-08-11 14:01     ` Arnd Bergmann [this message]
2016-08-11 14:06       ` Jan Beulich
2016-08-11 14:06       ` Jan Beulich
2016-08-11 14:01     ` Arnd Bergmann
2016-08-24 17:18   ` [Xen-devel] " David Vrabel
2016-08-24 17:18   ` David Vrabel
2016-08-11 12:39 ` Arnd Bergmann
2016-08-11 13:55 ` [EXPERIMENTAL] enable thin archives and --gc-sections on ARM Arnd Bergmann
2016-08-11 20:01   ` Nicolas Pitre
2016-08-11 20:37     ` Arnd Bergmann
2016-08-11 21:05       ` Nicolas Pitre
2016-08-23  6:17 ` [PATCH 0/6 v2] kbuild changes, thin archives, --gc-sections Nicholas Piggin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1924668.nNs2RHZJcd@wuerfel \
    --to=arnd@arndb.de \
    --cc=JBeulich@suse.com \
    --cc=JGross@suse.com \
    --cc=MMarek@suse.com \
    --cc=amodra@gmail.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=nico@linaro.org \
    --cc=npiggin@gmail.com \
    --cc=sam@ravnborg.org \
    --cc=segher@kernel.crashing.org \
    --cc=sfr@canb.auug.org.au \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.