On Fri, Aug 4, 2017 at 4:28 PM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 08/04/2017 09:31 PM, Rob Clark wrote:
For now, pending conclusion on proposal about using c11 and u"string" instead of L"string" plus -fshort-wchar.
Background: UEFI uses utf16 strings universally. An UEFI implementation that does not use -fshort-wchar has to do a lot of cumbersome charset conversion back/forth. Mixing object files that use -fshort-wchar and others that do not is a bad idea (and gcc will warn about it). There are 3 reasonable solutions that I can think of:
Use -fshort-wchar across the board. We don't dynamically link against other shared libraries at runtime, so there isn't much downside to this approach. Heinrich brought up ext4, which uses utf32, but I guess this mostly matters for fs_ls(), and it does not seem so bad for it to do utf32->utf8 conversion.
Use -fshort-wchar only if CONFIG_EFI_LOADER=y.. UEFI only requires fat/vfat so we don't need ext4 and efi loader at the same time.
Go with Heinrich's suggestion of requiring c11. Possibly this requirement could be loosened to only require c11 for efi loader. This seems like the best approach, and at least no one has so far brought up any objection to his proposal.
Not-signed-off-by: Rob Clark robdclark@gmail.com
Do I understand you right? You do not want the current version of the patch series merged?
nope, I fully expect review comments and updates, hence calling it "v0".. I just don't want it to be ignored, as is the tendency for large RFC's on other lists that I am on. Hence the "Not-signed-off-by" ;-)
It might have been better to replace [PATCH] by [RFC] in the subject lines of the patch set in this case.
I am currently trying to find out if the switch to C11 is possible, cf. https://travis-ci.org/xypron2/u-boot/builds/261098363.
Unfortunately Travis uses gcc 4.8.2 for some jobs which does not yet support C11.
Furthermore there seems to be some problem in disk/part_efi.c with PARTITION_SYSTEM_GUID.
hmm, link/pastebin error, and I can have a look? On my wip branch that included this patchset, plus other bits needed to make it work on db410c, I didn't see any such issues, but I might have screwed something up in splitting up the db410c and related fixes from the efi_loader patchset.
I do have some regressions on a couple of the vexpress boards, which are totally unrelated to the patch that introduces the regression and I cannot reproduce locally (although locally I have newer gcc and qemu). See [1] which is introduced by patch 15. I'm pretty sure this is a problem with the test environment (either gcc or qemu), but not quite sure what to do about it.
[1] https://travis-ci.org/robclark/u-boot/jobs/260997492
BR, -R
Best regards
Heinrich
config.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.mk b/config.mk index b77d58903c..5ad9e7198d 100644 --- a/config.mk +++ b/config.mk @@ -74,7 +74,7 @@ endif RELFLAGS := $(PLATFORM_RELFLAGS)
PLATFORM_CPPFLAGS += $(RELFLAGS) -PLATFORM_CPPFLAGS += -pipe +PLATFORM_CPPFLAGS += -pipe -fshort-wchar
LDFLAGS += $(PLATFORM_LDFLAGS) LDFLAGS_FINAL += -Bstatic