[PATCH v2] Ensure that MIPS target code is compiled for the O32 ABI.
Include -mabi=32 in CFLAGS_PLATFORM and CCASFLAGS_PLATFORM to compile code for the O32 ABI when targetting MIPS, since the MIPS assembly code in GRUB assumes this. This flag is also needed when compiling asm-tests/mips.S from configure, because GNU as rejects MIPS register names such as $t2 unless the O32 ABI is selected. This is needed when using a compiler that defaults to one of the newer MIPS ABIs such as N32 or N64, e.g. when natively compiling on a system that uses one of these newer MIPS ABIs. --- conf/Makefile.common | 4 configure.ac | 7 +-- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/conf/Makefile.common b/conf/Makefile.common index fcb8d2e..bd125da 100644 --- a/conf/Makefile.common +++ b/conf/Makefile.common @@ -20,6 +20,10 @@ endif if COND_powerpc_ieee1275 CFLAGS_PLATFORM += -mcpu=powerpc endif +if COND_mips + CFLAGS_PLATFORM += -mabi=32 + CCASFLAGS_PLATFORM = -mabi=32 +endif #FIXME: discover and check XEN headers CPPFLAGS_XEN = -I/usr/include diff --git a/configure.ac b/configure.ac index c864311..1f5e8a2 100644 --- a/configure.ac +++ b/configure.ac @@ -2,7 +2,8 @@ # Process this file with autoconf to produce a configure script. -# Copyright (C) 2002,2003,2004,2005,2006,2007,2008,2009,2010 Free Software Foundation, Inc. +# Copyright (C) 2002,2003,2004,2005,2006,2007,2008,2009,2010,2011, +# 2012,2013,2014,2015 Free Software Foundation, Inc. # # This configure.ac is free software; the author # gives unlimited permission to copy and/or distribute it, @@ -599,9 +600,11 @@ fi AC_CACHE_CHECK([for options to compile assembly], [grub_cv_cc_target_asm_compile], [ test_program= +test_ccasflags= case x$target_cpu-$platform in xmips-* | xmipsel-*) test_program=mips +test_ccasflags=-mabi=32 ;; xi386-pc) test_program=i386-pc @@ -618,7 +621,7 @@ if test x$test_program = x ; then else found=no for arg in -no-integrated-as; do -cmdline=$TARGET_CC -c -o /dev/null $TARGET_CCASFLAGS $arg $TARGET_CPPFLAGS $srcdir/asm-tests/$test_program.S +cmdline=$TARGET_CC -c -o /dev/null $TARGET_CCASFLAGS $test_ccasflags $arg $TARGET_CPPFLAGS $srcdir/asm-tests/$test_program.S echo Running $cmdline AS_MESSAGE_LOG_FD if $cmdline AS_MESSAGE_LOG_FD 2AS_MESSAGE_LOG_FD; then grub_cv_cc_target_asm_compile=$arg -- 2.5.0 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Ensure that MIPS target code is compiled for the O32 ABI.
24.08.2015 10:57, Mark H Weaver пишет:
Andrei Borzenkov arvidj...@gmail.com writes:
Could you paste clang -v output for both cases? I believe I
understand what's going on.
Okay, I've included it below. It might be relevant to mention that the
MIPS port of GNU Guix is not a 'multilib' system: it includes support
only for the N32 ABI. However, our gcc is still capable of generating
freestanding code for the O32 ABI, as demonstrated by the fact that I've
been successfully building and using GRUB on it.
Thanks,
Mark
--8---cut here---start-8---
mhw@librenote:~$ clang -v -mabi=32 mips.S
clang version 3.6.0 (tags/RELEASE_360/final)
Target: mips64el-unknown-linux-gnu
Yes, as expected. clang treats mips and mips64 as two different targets
so o32 is invalid for mips64.
Could you test attached patch for both gcc and clang? Use
configure TARGET_CC=clang
From: Andrei Borzenkov arvidj...@gmail.com
Subject: [PATCH] configure: try to force o32 ABI on MIPS
GRUB expects o32 ABI, in particular used assembly is valid only in this mode.
Some systems (e.g. GNU Guix) default to using newer n64 or n32 ABI. Try to
find suitable options to force o32.
For GCC this is simply -mabi=32. While clang supports this option as well,
o32 ABI is valid for MIPS target and n32/64 ABI are valid for MIPS64 target
only, so use -target mips -mabi=32.
Reported-By: Mark H Weaver m...@netris.org
Also-By: Mark H Weaver m...@netris.org
---
configure.ac | 29 +
1 file changed, 29 insertions(+)
diff --git a/configure.ac b/configure.ac
index c864311..d857e47 100644
--- a/configure.ac
+++ b/configure.ac
@@ -597,6 +597,35 @@ int main (void);
TARGET_LDFLAGS=$TARGET_LDFLAGS $grub_cv_target_cc_big_endian
fi
+if test x$target_cpu = xmips || test x$target_cpu = xmipsel ; then
+ AC_CACHE_CHECK([for options to force MIPS o32 ABI], grub_cv_target_cc_mips_o32_abi, [
+grub_cv_target_cc_mips_o32_abi=no
+for arg in -mabi=32 -target mips -mabi=32
+ if test x$grub_cv_target_cc_mips_o32_abi != xno ; then
+break
+ fi
+ CFLAGS=$TARGET_CFLAGS $arg -Werror
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([[
+#if !defined(_ABIO32) || !defined(_MIPS_SIM) || (_MIPS_SIM != _ABIO32)
+#error not o32 ABI
+#endif
+asm (.globl start; start:);
+void __main (void);
+void __main (void) {}
+int main (void);
+]], [[]])],
+ [grub_cv_target_cc_mips_o32_abi=$arg], [])
+done
+ ])
+
+ if test x$grub_cv_target_cc_mips_o32_abi = xno ; then
+AC_MSG_ERROR([could not force MIPS o32 ABI])
+ fi
+
+ TARGET_CFLAGS=$TARGET_CFLAGS $grub_cv_target_cc_mips_o32_abi
+ TARGET_CCASFLAGS=$TARGET_CCASFLAGS $grub_cv_target_cc_mips_o32_abi
+fi
+
AC_CACHE_CHECK([for options to compile assembly], [grub_cv_cc_target_asm_compile], [
test_program=
case x$target_cpu-$platform in
--
tg: (ba218c1..) u/mips-o32 (depends on: master)
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Ensure that MIPS target code is compiled for the O32 ABI.
22.08.2015 21:04, Mark H Weaver пишет: Andrei Borzenkov arvidj...@gmail.com writes: 19.08.2015 21:35, Mark H Weaver пишет: Include -mabi=32 in CFLAGS_PLATFORM and CCASFLAGS_PLATFORM to compile code for the O32 ABI when targetting MIPS, since the MIPS assembly code in GRUB assumes this. This flag is also needed when compiling asm-tests/mips.S from configure, because GNU as rejects MIPS register names such as $t2 unless the O32 ABI is selected. --- conf/Makefile.common | 4 configure.ac | 7 +-- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/conf/Makefile.common b/conf/Makefile.common index fcb8d2e..bd125da 100644 --- a/conf/Makefile.common +++ b/conf/Makefile.common @@ -20,6 +20,10 @@ endif if COND_powerpc_ieee1275 CFLAGS_PLATFORM += -mcpu=powerpc endif +if COND_mips + CFLAGS_PLATFORM += -mabi=32 + CCASFLAGS_PLATFORM = -mabi=32 +endif Does it work with clang? Based on the error message below, clang seems to accept and understand the -mabi=32 option, but the version of clang that we have in GNU Guix (which uses the N32 ABI on MIPS) seems to lack support for compiling for O32: mhw@librenote:~$ clang -mabi=32 mips.S error: unknown target CPU 'mips32r2' However, it doesn't work without that option either: mhw@librenote:~$ clang mips.S mips.S: Assembler messages: mips.S:7: Error: invalid operands `ld $t2,0($t6)' mips.S:10: Error: invalid operands `addiu $t7,$s0,(b-a)' clang-3.6: error: assembler command failed with exit code 1 (use -v to see invocation) This is the same failure that occurs with gcc when configured to use the N32 ABI by default. I also tried passing -fno-integrated-as in both cases above, but it made no difference. Could you paste clang -v output for both cases? I believe I understand what's going on. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Ensure that MIPS target code is compiled for the O32 ABI.
24.08.2015 11:12, Andrei Borzenkov пишет:
24.08.2015 10:57, Mark H Weaver пишет:
Andrei Borzenkov arvidj...@gmail.com writes:
Could you paste clang -v output for both cases? I believe I
understand what's going on.
Okay, I've included it below. It might be relevant to mention that the
MIPS port of GNU Guix is not a 'multilib' system: it includes support
only for the N32 ABI. However, our gcc is still capable of generating
freestanding code for the O32 ABI, as demonstrated by the fact that I've
been successfully building and using GRUB on it.
Thanks,
Mark
--8---cut here---start-8---
mhw@librenote:~$ clang -v -mabi=32 mips.S
clang version 3.6.0 (tags/RELEASE_360/final)
Target: mips64el-unknown-linux-gnu
Yes, as expected. clang treats mips and mips64 as two different targets
so o32 is invalid for mips64.
Could you test attached patch for both gcc and clang? Use
configure TARGET_CC=clang
Sorry, was broken, fixed version attached.
From: Andrei Borzenkov arvidj...@gmail.com
Subject: [PATCH] configure: try to force o32 ABI on MIPS
GRUB expects o32 ABI, in particular used assembly is valid only in this mode.
Some systems (e.g. GNU Guix) default to using newer n64 or n32 ABI. Try to
find suitable options to force o32.
For GCC this is simply -mabi=32. While clang supports this option as well,
o32 ABI is valid for MIPS target and n32/64 ABI are valid for MIPS64 target
only, so use -target mips -mabi=32.
Reported-By: Mark H Weaver m...@netris.org
Also-By: Mark H Weaver m...@netris.org
---
configure.ac | 29 +
1 file changed, 29 insertions(+)
diff --git a/configure.ac b/configure.ac
index c864311..2e73b3f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -597,6 +597,35 @@ int main (void);
TARGET_LDFLAGS=$TARGET_LDFLAGS $grub_cv_target_cc_big_endian
fi
+if test x$target_cpu = xmips || test x$target_cpu = xmipsel ; then
+ AC_CACHE_CHECK([for options to force MIPS o32 ABI], grub_cv_target_cc_mips_o32_abi, [
+grub_cv_target_cc_mips_o32_abi=no
+for arg in -mabi=32 -target mips -mabi=32 ; do
+ if test x$grub_cv_target_cc_mips_o32_abi != xno ; then
+break
+ fi
+ CFLAGS=$TARGET_CFLAGS $arg -Werror
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([[
+#if !defined(_ABIO32) || !defined(_MIPS_SIM) || (_MIPS_SIM != _ABIO32)
+#error not o32 ABI
+#endif
+asm (.globl start; start:);
+void __main (void);
+void __main (void) {}
+int main (void);
+]], [[]])],
+ [grub_cv_target_cc_mips_o32_abi=$arg], [])
+done
+ ])
+
+ if test x$grub_cv_target_cc_mips_o32_abi = xno ; then
+AC_MSG_ERROR([could not force MIPS o32 ABI])
+ fi
+
+ TARGET_CFLAGS=$TARGET_CFLAGS $grub_cv_target_cc_mips_o32_abi
+ TARGET_CCASFLAGS=$TARGET_CCASFLAGS $grub_cv_target_cc_mips_o32_abi
+fi
+
AC_CACHE_CHECK([for options to compile assembly], [grub_cv_cc_target_asm_compile], [
test_program=
case x$target_cpu-$platform in
--
tg: (ba218c1..) u/mips-o32 (depends on: master)
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 09/23] efi: create efi_enabled()
On 22.08.15 at 14:33, daniel.ki...@oracle.com wrote:
On Thu, Aug 20, 2015 at 09:18:17AM -0600, Jan Beulich wrote:
On 20.07.15 at 16:29, daniel.ki...@oracle.com wrote:
--- a/xen/arch/x86/efi/stub.c
+++ b/xen/arch/x86/efi/stub.c
@@ -4,9 +4,14 @@
#include xen/lib.h
#include asm/page.h
-#ifndef efi_enabled
-const bool_t efi_enabled = 0;
-#endif
+struct efi __read_mostly efi = {
+ .flags = 0, /* Initialized later. */
+ .acpi= EFI_INVALID_TABLE_ADDR,
+ .acpi20 = EFI_INVALID_TABLE_ADDR,
+ .mps = EFI_INVALID_TABLE_ADDR,
+ .smbios = EFI_INVALID_TABLE_ADDR,
+ .smbios3 = EFI_INVALID_TABLE_ADDR
+};
How is this change related to the subject of the patch?
I need to add this struct because...
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -191,8 +191,6 @@ SECTIONS
.pad : {
. = ALIGN(MB(16));
} :text
-#else
- efi = .;
#endif
Same here.
...this creates efi symbol to just satisfy linker and I am removing it.
However, existing solution does not allocate space for this symbol and
any references to acpi20, etc. does not make sense. As I saw any efi.*
references are protected by relevant ifs but we should not do that because
it makes code very fragile. If somebody does not know how efi symbol is
created he/she may assume that it always represent valid structure and
do invalid references somewhere. So, I still think that stub.c should
define efi struct properly even if we assume that flags should not be
there. However, I agree that this could be separate patch.
By the way why did you choose so strange way to satisfy liker needs?
To me there's nothing strange about it: I want a symbol that
occupies no space in memory.
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -717,6 +717,10 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE
*SystemTable)
char *option_str;
bool_t use_cfg_file;
+#ifndef CONFIG_ARM /* Disabled until runtime services implemented. */
+set_bit(EFI_PLATFORM, efi.flags);
+#endif
Just for this to work? I don't see the need for all the pointers in
the stub case - why can't this be a separate variable? We don't
Could be but if we create struct with so generic name like just simple
efi it suggest that this is good place to put flags there. If it is not
how to call it? efi_flags? Or maybe we should rename efi to efi_tables
too. Then everything will be clear.
I agree that this may be matter of taste, but to me the current
naming looks quite fine. And yes, efi_flags of efi_state would be
a fine name. In general I wouldn't even mind it to be a field in
the structure, if only that resulted in the _full_ structure to be
allocated even in the no-EFI build case. I admit though that with
the goal of always building EFI code (unless the tool chain
doesn't support doing so) this becomes less of an issue; otoh us
probably wanting some Kconfig-like mechanism sooner or later to
{en,dis}able certain features would call for this to remain separable.
And yes, at that point it could be done by #ifdef-ing out everything
by the flags member.
So based on the above I'm withdrawing my implied objection, but
please make sure you write better patch descriptions explaining
what is done and _why_.
Jan
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 10/23] efi: build xen.gz with EFI code
On 22.08.15 at 15:59, daniel.ki...@oracle.com wrote: On Thu, Aug 20, 2015 at 09:39:39AM -0600, Jan Beulich wrote: On 20.07.15 at 16:29, daniel.ki...@oracle.com wrote: Build xen.gz with EFI code. We need this to support multiboot2 protocol on EFI platforms. If we wish to load not ELF file using multiboot (v1) or multiboot2 then DYM a non-ELF file? it must contain linear (or flat) representation of code and data. Why? Please don't just put out statements, but also reasons (i.e. at least which component is unable to deal with the current [valid afaict] PE image we have). This is a requirement of multiboot (v1) or multiboot2 protocol. They both know nothing about PE image format. And hence how specifically we arrange data inside the image should be benign to them, as they won't be able to load the file _anyway_. Currently, PE file contains many sections which are not linear (one after another without any holes) or even do not have representation in a file (e.g. BSS). In theory there is a chance that we could build proper PE file using current build system. However, it means that What is improper about the currently built PE file? And if there is anything improper, did you inform the binutils maintainers of the problem? From PE loader point of view everything is OK. However, current Xen PE image (at least build on my machines) is not usable by multiboot (v1) or multiboot2 protocol compatible loader because it is not linear (one section does not live immediately after another without any voids). Again - either I'm missing something (and then your explanation is not good enough) or this is (as said above) a pointless adjustment. --- a/xen/arch/x86/efi/Makefile +++ b/xen/arch/x86/efi/Makefile @@ -1,14 +1,16 @@ CFLAGS += -fshort-wchar -obj-y += stub.o - -create = test -e $(1) || touch -t 19990101 $(1) - efi := $(filter y,$(x86_64)$(shell rm -f disabled)) efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c check.c 2disabled echo y)) efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi check.o disabled echo y)) -efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call create,boot.init.o); $(call create,runtime.o))) +efi := $(if $(efi),$(shell rm disabled)y) -extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o +extra-y += relocs-dummy.o Why is this no longer extra-$(efi)? Because we need proper EFI code in xen.gz to support boot via multiboot2 on EFI platforms. What would we need that for when not building an EFI-capable binary anyway? -stub.o: $(extra-y) With this dependency removed (instead of perhaps replaced or extended) - what will trigger relocs-dummy.o to be (re)built? It is triggered by prelink.o build rule in xen/arch/x86/Makefile. No. Or better - if it is, then this is wrong. With the way our build logic works, unless there are exceptional circumstances things in a certain directory should be built _only_ when recursion reaches that particular directory (i.e. not from any of its parents). Jan ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Ensure that MIPS target code is compiled for the O32 ABI.
Andrei Borzenkov arvidj...@gmail.com writes: Could you paste clang -v output for both cases? I believe I understand what's going on. Okay, I've included it below. It might be relevant to mention that the MIPS port of GNU Guix is not a 'multilib' system: it includes support only for the N32 ABI. However, our gcc is still capable of generating freestanding code for the O32 ABI, as demonstrated by the fact that I've been successfully building and using GRUB on it. Thanks, Mark --8---cut here---start-8--- mhw@librenote:~$ clang -v -mabi=32 mips.S clang version 3.6.0 (tags/RELEASE_360/final) Target: mips64el-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /gnu/store/1phn21k7w04nsc38zlzrslqcqivcn714-gcc-4.9.3-lib/lib/gcc/mips64el-unknown-linux-gnu/4.9.3 Selected GCC installation: /gnu/store/1phn21k7w04nsc38zlzrslqcqivcn714-gcc-4.9.3-lib/lib/gcc/mips64el-unknown-linux-gnu/4.9.3 Candidate multilib: .; Selected multilib: .; /gnu/store/hy0fp4z8ar362cnry5ifwmcrq2nqmjfc-clang-3.6.0/bin/clang-3.6 -cc1 -triple mips64el-unknown-linux-gnu -E -disable-free -disable-llvm-verifier -main-file-name mips.S -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -no-integrated-as -mconstructor-aliases -fuse-init-array -target-cpu mips32r2 -target-feature -n64 -target-feature +o32 -target-abi o32 -mfloat-abi hard -v -dwarf-column-info -resource-dir /gnu/store/hy0fp4z8ar362cnry5ifwmcrq2nqmjfc-clang-3.6.0/bin/../lib/clang/3.6.0 -I/home/mhw/.guix-profile/include -internal-isystem /usr/local/include -internal-isystem /gnu/store/hy0fp4z8ar362cnry5ifwmcrq2nqmjfc-clang-3.6.0/bin/../lib/clang/3.6.0/include -internal-externc-isystem /gnu/store/cncig2c9n92ndz97pw0ply1jjc0xycmf-glibc-2.21/include -fno-dwarf-directory-asm -fdebug-compilation-dir /home/mhw -ferror-limit 19 -fmessage-length 0 -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -o /tmp/mips-a6494a.s -x assembler-with-cpp mips.S error: unknown target CPU 'mips32r2' mhw@librenote:~$ clang -v mips.S clang version 3.6.0 (tags/RELEASE_360/final) Target: mips64el-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /gnu/store/1phn21k7w04nsc38zlzrslqcqivcn714-gcc-4.9.3-lib/lib/gcc/mips64el-unknown-linux-gnu/4.9.3 Selected GCC installation: /gnu/store/1phn21k7w04nsc38zlzrslqcqivcn714-gcc-4.9.3-lib/lib/gcc/mips64el-unknown-linux-gnu/4.9.3 Candidate multilib: .; Selected multilib: .; /gnu/store/hy0fp4z8ar362cnry5ifwmcrq2nqmjfc-clang-3.6.0/bin/clang-3.6 -cc1 -triple mips64el-unknown-linux-gnu -E -disable-free -disable-llvm-verifier -main-file-name mips.S -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -no-integrated-as -mconstructor-aliases -fuse-init-array -target-cpu mips64r2 -target-feature -o32 -target-feature +n64 -target-abi n64 -mfloat-abi hard -v -dwarf-column-info -resource-dir /gnu/store/hy0fp4z8ar362cnry5ifwmcrq2nqmjfc-clang-3.6.0/bin/../lib/clang/3.6.0 -I/home/mhw/.guix-profile/include -internal-isystem /usr/local/include -internal-isystem /gnu/store/hy0fp4z8ar362cnry5ifwmcrq2nqmjfc-clang-3.6.0/bin/../lib/clang/3.6.0/include -internal-externc-isystem /gnu/store/cncig2c9n92ndz97pw0ply1jjc0xycmf-glibc-2.21/include -fno-dwarf-directory-asm -fdebug-compilation-dir /home/mhw -ferror-limit 19 -fmessage-length 0 -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -o /tmp/mips-aee666.s -x assembler-with-cpp mips.S clang -cc1 version 3.6.0 based upon LLVM 3.6.0 default target mips64el-unknown-linux-gnu #include ... search starts here: #include ... search starts here: /home/mhw/.guix-profile/include /usr/local/include /gnu/store/hy0fp4z8ar362cnry5ifwmcrq2nqmjfc-clang-3.6.0/bin/../lib/clang/3.6.0/include /gnu/store/cncig2c9n92ndz97pw0ply1jjc0xycmf-glibc-2.21/include End of search list. /home/mhw/.guix-profile/bin/as -march mips64r2 -mabi 64 -mno-shared -KPIC -EL -o /tmp/mips-e5abd7.o /tmp/mips-aee666.s mips.S: Assembler messages: mips.S:7: Error: invalid operands `ld $t2,0($t6)' mips.S:10: Error: invalid operands `addiu $t7,$s0,(b-a)' clang-3.6: error: assembler command failed with exit code 1 (use -v to see invocation) mhw@librenote:~$ --8---cut here---end---8--- ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 0/6] multiboot2: Add two extensions and fix some issues
Guys, especially GRUB2 maintainers, On Mon, Jul 20, 2015 at 04:35:48PM +0200, Daniel Kiper wrote: Hi, This patch series: - enables EFI boot services usage in loaded images by multiboot2 protocol, - add support for multiboot2 protocol compatible relocatable images, - fixes two minor issues. Is it possible to get your comments to this patch series (I would like to thank you Andrei and Konrad for review)? We need this functionality as Xen community and as Oracle. Hence, it will be nice to know that we go in good direction. So, if you think that we should change something please drop me a line. I know that you are busy but please, at least, tell us when you take a look at it. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB release schedule?
On Sat, Aug 22, 2015 at 08:16:26AM +0300, Andrei Borzenkov wrote: 21.08.2015 21:41, Konrad Rzeszutek Wilk пишет: Lets start with a list of priorities: - What are the most important platforms after x86? I suppose distribution-wise they are ARM and PPC. This means 5 different GRUB builds. MIPS seems to be still in use, at least there are patches and bug reports. x86-32 (BIOS) x86-EFI ARM-32 ARM-64 ARM-EFI ? PPC-32 PPC-64 ? - What are the most important tests that MUST PASS all the time? All of them actually. There is one test that unfortunately is bound to fail unless built in controlled environment. Can the test be skipped if the environment is not controlled? - Which ones have been FAILing for years? Hard to know, there are no published results. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 10/23] efi: build xen.gz with EFI code
On Mon, Aug 24, 2015 at 05:35:21AM -0600, Jan Beulich wrote: On 22.08.15 at 15:59, daniel.ki...@oracle.com wrote: On Thu, Aug 20, 2015 at 09:39:39AM -0600, Jan Beulich wrote: On 20.07.15 at 16:29, daniel.ki...@oracle.com wrote: Build xen.gz with EFI code. We need this to support multiboot2 protocol on EFI platforms. If we wish to load not ELF file using multiboot (v1) or multiboot2 then DYM a non-ELF file? it must contain linear (or flat) representation of code and data. Why? Please don't just put out statements, but also reasons (i.e. at least which component is unable to deal with the current [valid afaict] PE image we have). This is a requirement of multiboot (v1) or multiboot2 protocol. They both know nothing about PE image format. And hence how specifically we arrange data inside the image should be benign to them, as they won't be able to load the file _anyway_. Currently, PE file contains many sections which are not linear (one after another without any holes) or even do not have representation in a file (e.g. BSS). In theory there is a chance that we could build proper PE file using current build system. However, it means that What is improper about the currently built PE file? And if there is anything improper, did you inform the binutils maintainers of the problem? From PE loader point of view everything is OK. However, current Xen PE image (at least build on my machines) is not usable by multiboot (v1) or multiboot2 protocol compatible loader because it is not linear (one section does not live immediately after another without any voids). Again - either I'm missing something (and then your explanation is not good enough) or this is (as said above) a pointless adjustment. Let's focus on multiboot2 protocol (multiboot (v1) is similar to multiboot2 in discussed case). In general multiboot2 is able to load any file which has: 1. proper multiboot2 header in first 32 KiB of a given file, 2. the text and data segments must be consecutive in the OS image (The Multiboot Specification version 1.6). This implies that we can e.g. build valid ELF file which is also multiboot2 protocol compatible image. And we does. However, we can go further. Potentially we can build valid PE image which is also valid multiboot2 protocol image. Although current build method does not satisfy requirement number 2 because, e.g.: Sections: Idx Name Size VMA LMA File off Algn 0 .text 001513d0 82d08020 82d08020 1000 2**12 ^^ CONTENTS, ALLOC, LOAD, CODE 1 .rodata 0004de12 82d0803513e0 82d0803513e0 00153000 2**5 ^^ CONTENTS, ALLOC, LOAD, READONLY, DATA Hence, we must use special method to build PE image (I discussed that in my earlier email in that topic) to do it compatible with multiboot2 protocol. This way one file could be loaded by native PE loader, mulitboot (v1) protocol (it requires relevant header but it does not interfere with PE and multiboot2 protocol stuff) and mutliboot2 protocol compatible loaders. Additionally, if it is signed with Secure Boot signature then potentially signature could be verified by UEFI itself and e.g. GRUB2. However, as I said earlier this requires more work and this is next step which I am going to do after applying this series. Currently I am going to embed EFI support into ELF file because it is easy (less changes; currently used ELF file has required properties because multiboot (v1) which we use has similar requirements like multiboot2 protocol) to make it compatible with multiboot2 protocol. I hope that helps. --- a/xen/arch/x86/efi/Makefile +++ b/xen/arch/x86/efi/Makefile @@ -1,14 +1,16 @@ CFLAGS += -fshort-wchar -obj-y += stub.o - -create = test -e $(1) || touch -t 19990101 $(1) - efi := $(filter y,$(x86_64)$(shell rm -f disabled)) efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c check.c 2disabled echo y)) efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi check.o disabled echo y)) -efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call create,boot.init.o); $(call create,runtime.o))) +efi := $(if $(efi),$(shell rm disabled)y) -extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o +extra-y += relocs-dummy.o Why is this no longer extra-$(efi)? Because we need proper EFI code in xen.gz to support boot via multiboot2 on EFI platforms. What would we need that for when not building an EFI-capable binary anyway? xen/arch/x86/efi/stub.c Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
