Re: [PATCH] remove target_os
On Sat, Feb 07, 2009 at 10:54:32PM +0100, Robert Millan wrote: On Tue, Jan 27, 2009 at 08:56:59PM +0100, Christian Franke wrote: Robert: Patch is IMO GTG. Ok. If noone objects I'll check it in soon. Committed. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] remove target_os
On Mon, Jan 26, 2009 at 08:57:10PM +0100, Christian Franke wrote: But even if GRUB itself is build for some $target_cpu-$target_vendor (i386-pc), the target_os is not useless if cross-compilation support is desired: - GRUB tools like grub-setup are build for the target_os - Package structure may depend on target_os. That would be host_os. Consider this example: a system running on cpu FOO cross-compiles grub (i.e. stuff like grub-probe or grub-mkimage) so that it will run on cpu BAR. However, grub-mkimage should generate images for cpu BAZ (accordingly, the modules are built for BAZ too). This means build_cpu=FOO host_cpu=BAR target_cpu=BAZ. host_os, then, is the OS that runs on BAR. It isn't necessarily related to BAZ. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
remove OS part of --target=xxx (Re: [PATCH] remove target_os)
On Tue, Jan 27, 2009 at 06:33:47PM +0100, Javier Martín wrote: So you propose --target to be reused like this (a PS3 building GRUB2 for an amd64 BIOS PC with Linux) : ./configure --build=ppc64-linux --host=x86_64-linux-gnu --target=i686-pc ^--compiling system ^--tools system ^--boot arch I'm not proposing to change the way --target is used, only describing what its argument is supposed to mean, based on a comment from configure.ac. I agree that having to specify an OS for --target in command-line is odd too, but it's a different problem. Maybe we could ask the config.sub maintainer for a dummy value, such as unknown or so (I think Glibc had a --host for standalone -no OS- arm builds, perhaps we could use the same). I think we already have a better-geared switch for that (--with-platform it is?), which is currently used to distinguish between BIOS and EFI boot code on both x86 and x86-64. --with-platform is an override for the default platform that is otherwise derived from target_vendor, AFAIK. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] remove target_os
On Tue, Jan 27, 2009 at 08:56:59PM +0100, Christian Franke wrote: Robert: Patch is IMO GTG. Ok. If noone objects I'll check it in soon. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] remove target_os
Javier Martín wrote: A, say, AMD64 Linux cross compiler hosted on x86 Cygwin would have $build=i686-pc-cygwin and $host=amd64-linux-gnu. Thus, no conflict ought to arise even with cross compilation enabled. AFAIK, the full power of $build+$host+$target only matters when building _compilers_ (and binutils, etc.), because you might want to use an AMD64/Linux machine to build a compiler that will run on PPC/Darwin but produce executables for a x86/Cygwin machine Now lets move this idea to GRUB 2: There is a build server is running on PPC/Linux and it wants to build all architectures supported by GRUB 2 (provide proper boot code for all arch and tools) and then makes software bundles (rpm,deb, or so) for all architectures. In example if all shell tools are to be ran on x86-64/Linux and then boot code needs to be compatible with x86-32 as there is PC-BIOS present on target system. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] remove target_os
Javier Martín wrote:
Unfortunately, gcc has no '-fno_os' option to specify the bare CPU as
target.
Might -ffreestanding be what you are looking for?
The option '-ffreestanding' is the same as '-fno-hosted'.
According to gcc (4.3.1) source, '-fno-hosted' clears variable
'flag_hosted' and sets '-fno-builtin'. The latter is already set within
GRUB build.
A cleared 'flag_hosted' apparently has only 2 effects:
- disable the special handling of 'main()'.
- #define __STDC_HOSTED__ to 0 instead of 1
There is no effect on the target_os dependent parts of the gcc code
generation. For example, on i386, __enable_execute_stack() calls are
generated for target_os netbsd, openbsd and cygwin, but not for linux.
The emit call is hard-coded in
gcc/configs/i386/i386.c:x86_initialize_trampoline().
Other workarounds are needed to support building GRUB with code
generators tailored for various target_os.
AC_MSG_CHECKING([for command to convert module to ELF format])
-case ${host_os}:${target_os} in
- cygwin:cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
+case ${host_os} in
+ cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
*) ;;
esac
This won't work for a Linux cross compiler hosted on Cygwin. It would
emit ELF format and does not need pe2elf.
A, say, AMD64 Linux cross compiler hosted on x86 Cygwin would have
$build=i686-pc-cygwin and $host=amd64-linux-gnu. Thus, no conflict ought
to arise even with cross compilation enabled.
But the opposite won't work: $host=i686-pc-cygwin would enable
grub-pe2elf, even if this gcc emits ELF for a linux target.
Christian
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] remove target_os
El mar, 27-01-2009 a las 18:51 +0200, Vesa Jääskeläinen escribió: Javier Martín wrote: A, say, AMD64 Linux cross compiler hosted on x86 Cygwin would have $build=i686-pc-cygwin and $host=amd64-linux-gnu. Thus, no conflict ought to arise even with cross compilation enabled. AFAIK, the full power of $build+$host+$target only matters when building _compilers_ (and binutils, etc.), because you might want to use an AMD64/Linux machine to build a compiler that will run on PPC/Darwin but produce executables for a x86/Cygwin machine Now lets move this idea to GRUB 2: There is a build server is running on PPC/Linux and it wants to build all architectures supported by GRUB 2 (provide proper boot code for all arch and tools) and then makes software bundles (rpm,deb, or so) for all architectures. In example if all shell tools are to be ran on x86-64/Linux and then boot code needs to be compatible with x86-32 as there is PC-BIOS present on target system. So you propose --target to be reused like this (a PS3 building GRUB2 for an amd64 BIOS PC with Linux) : ./configure --build=ppc64-linux --host=x86_64-linux-gnu --target=i686-pc ^--compiling system ^--tools system ^--boot arch I think we already have a better-geared switch for that (--with-platform it is?), which is currently used to distinguish between BIOS and EFI boot code on both x86 and x86-64. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] remove target_os
El mar, 27-01-2009 a las 18:21 +0100, Christian Franke escribió:
Javier Martín wrote:
Unfortunately, gcc has no '-fno_os' option to specify the bare CPU as
target.
Might -ffreestanding be what you are looking for?
The option '-ffreestanding' is the same as '-fno-hosted'.
According to gcc (4.3.1) source, '-fno-hosted' clears variable
'flag_hosted' and sets '-fno-builtin'. The latter is already set within
GRUB build.
A cleared 'flag_hosted' apparently has only 2 effects:
- disable the special handling of 'main()'.
- #define __STDC_HOSTED__ to 0 instead of 1
There is no effect on the target_os dependent parts of the gcc code
generation. For example, on i386, __enable_execute_stack() calls are
generated for target_os netbsd, openbsd and cygwin, but not for linux.
The emit call is hard-coded in
gcc/configs/i386/i386.c:x86_initialize_trampoline().
In that case, we are dealing with a GCC bug. We might want to require
the user to create a bare no-OS cross compiler. These thingies are
most likely only known to OS developers, but you can build a perfectly
good i686-pc-elf GCC (only with no libc, of course). This might be the
Right Way (TM) of building boot code, instead of the current way of
using the OS-targetter compiler and trying to tell it not to do what it
was built to do.
Other workarounds are needed to support building GRUB with code
generators tailored for various target_os.
AC_MSG_CHECKING([for command to convert module to ELF format])
-case ${host_os}:${target_os} in
- cygwin:cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
+case ${host_os} in
+ cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
*) ;;
esac
This won't work for a Linux cross compiler hosted on Cygwin. It would
emit ELF format and does not need pe2elf.
A, say, AMD64 Linux cross compiler hosted on x86 Cygwin would have
$build=i686-pc-cygwin and $host=amd64-linux-gnu. Thus, no conflict ought
to arise even with cross compilation enabled.
But the opposite won't work: $host=i686-pc-cygwin would enable
grub-pe2elf, even if this gcc emits ELF for a linux target.
The opposite of a the described situation would be a Linux AMD64
machine cross compiling for a Cygwin x86 machine, that is
$build=amd64-linux-gnu and $host=i686-pc-cygwin. In that case,
i686-pc-cygwin-gcc would generate PE executables, and thus grub-pe2elf
_is_ required indeed.
Christian
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] remove target_os
Javier Martín wrote:
El mar, 27-01-2009 a las 18:21 +0100, Christian Franke escribió:
Javier Martín wrote:
Unfortunately, gcc has no '-fno_os' option to specify the bare CPU as
target.
Might -ffreestanding be what you are looking for?
The option '-ffreestanding' is the same as '-fno-hosted'.
According to gcc (4.3.1) source, '-fno-hosted' clears variable
'flag_hosted' and sets '-fno-builtin'. The latter is already set within
GRUB build.
A cleared 'flag_hosted' apparently has only 2 effects:
- disable the special handling of 'main()'.
- #define __STDC_HOSTED__ to 0 instead of 1
There is no effect on the target_os dependent parts of the gcc code
generation. For example, on i386, __enable_execute_stack() calls are
generated for target_os netbsd, openbsd and cygwin, but not for linux.
The emit call is hard-coded in
gcc/configs/i386/i386.c:x86_initialize_trampoline().
In that case, we are dealing with a GCC bug. We might want to require
the user to create a bare no-OS cross compiler.
Is building a bare 'no-OS' compiler supported by the upstream GCC sources?
Probably a too strict prerequisite for building GRUB.
AC_MSG_CHECKING([for command to convert module to ELF format])
-case ${host_os}:${target_os} in
- cygwin:cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
+case ${host_os} in
+ cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
*) ;;
esac
This won't work for a Linux cross compiler hosted on Cygwin. It would
emit ELF format and does not need pe2elf.
A, say, AMD64 Linux cross compiler hosted on x86 Cygwin would have
$build=i686-pc-cygwin and $host=amd64-linux-gnu. Thus, no conflict ought
to arise even with cross compilation enabled.
But the opposite won't work: $host=i686-pc-cygwin would enable
grub-pe2elf, even if this gcc emits ELF for a linux target.
The opposite of a the described situation would be a Linux AMD64
machine cross compiling for a Cygwin x86 machine, that is
$build=amd64-linux-gnu and $host=i686-pc-cygwin. In that case,
i686-pc-cygwin-gcc would generate PE executables, and thus grub-pe2elf
_is_ required indeed.
Yes - I was wrong, sorry.
Robert: Patch is IMO GTG.
Christian
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] remove target_os
Robert Millan wrote:
Hi,
Based on the description of host/target triplets in configure.ac:
dnl build -- the environment for building GRUB
dnl host -- the environment for running utilities
dnl target -- the environment for running GRUB
it seems that target_os is an oxymoron. There's no OS in the environment
where GRUB will run (well, there's the firmware, but we already use
target_vendor for that, and _os has a well-defined meaning).
Attached patch fixes that by supressing all references to target_os, and
replacing them with host_os where suitable.
Christian: since this mostly affects Cygwin, could you verify that it doesn't
cause breakage before I commit it?
Hi Robert,
thanks for sending the patch first. Cygwin build looks good.
But even if GRUB itself is build for some $target_cpu-$target_vendor
(i386-pc), the target_os is not useless if cross-compilation support is
desired:
- GRUB tools like grub-setup are build for the target_os
- Package structure may depend on target_os.
- The gcc code generator may emit special code tailored for the assumed
target_os
Examples:
Stack frame checks
Nested function trampolines (__enable_execute_stack())
Unfortunately, gcc has no '-fno_os' option to specify the bare CPU as
target.
Fortunately, all current issues can be handled by autoconf checks.
AC_MSG_CHECKING([for command to convert module to ELF format])
-case ${host_os}:${target_os} in
- cygwin:cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
+case ${host_os} in
+ cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
*) ;;
esac
This won't work for a Linux cross compiler hosted on Cygwin. It would
emit ELF format and does not need pe2elf.
But all this is theoretical unless cross compilation is really needed.
Christian
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] remove target_os
Hi,
Based on the description of host/target triplets in configure.ac:
dnl build -- the environment for building GRUB
dnl host -- the environment for running utilities
dnl target -- the environment for running GRUB
it seems that target_os is an oxymoron. There's no OS in the environment
where GRUB will run (well, there's the firmware, but we already use
target_vendor for that, and _os has a well-defined meaning).
Attached patch fixes that by supressing all references to target_os, and
replacing them with host_os where suitable.
Christian: since this mostly affects Cygwin, could you verify that it doesn't
cause breakage before I commit it?
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
2009-01-26 Robert Millan r...@aybabtu.com
* Makefile.in (host_os, host_cpu): New variables.
(target_os): Remove. Update all users.
Index: Makefile.in
===
--- Makefile.in (revision 1954)
+++ Makefile.in (working copy)
@@ -47,8 +47,10 @@ PACKAGE_VERSION = @PACKAGE_VERSION@
PACKAGE_STRING = @PACKAGE_STRING@
PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
+host_os = @host_os@
+host_cpu = @host_cpu@
+
target_cpu = @target_cpu@
-target_os = @target_os@
platform = @platform@
INSTALL = @INSTALL@
Index: conf/common.rmk
===
--- conf/common.rmk (revision 1954)
+++ conf/common.rmk (working copy)
@@ -146,7 +146,7 @@ CLEANFILES += update-grub_lib
./config.status --file=$@:$
chmod +x $@
grub-mkconfig_SCRIPTS = 00_header 10_linux 10_hurd 10_freebsd 30_os-prober 40_custom
-ifeq ($(target_os), cygwin)
+ifeq ($(host_os), cygwin)
grub-mkconfig_SCRIPTS += 10_windows
endif
Index: configure.ac
===
--- configure.ac (revision 1955)
+++ configure.ac (working copy)
@@ -103,12 +103,10 @@ case $host_os in
mingw32) host_os=cygwin ;;
esac
-case $target_os in
- mingw32) target_os=cygwin ;;
-esac
+AC_SUBST(host_cpu)
+AC_SUBST(host_os)
AC_SUBST(target_cpu)
-AC_SUBST(target_os)
AC_SUBST(platform)
#
@@ -200,10 +198,10 @@ AC_CHECK_FUNCS(posix_memalign memalign a
# Use linker script if present, otherwise use builtin -N script.
AC_MSG_CHECKING([for option to link raw image])
-if test -f ${srcdir}/conf/${target_cpu}-${platform}-${target_os}-img-ld.sc; then
- TARGET_IMG_LDSCRIPT='$(top_srcdir)'/conf/${target_cpu}-${platform}-${target_os}-img-ld.sc
+if test -f ${srcdir}/conf/${target_cpu}-${platform}-${host_os}-img-ld.sc; then
+ TARGET_IMG_LDSCRIPT='$(top_srcdir)'/conf/${target_cpu}-${platform}-${host_os}-img-ld.sc
TARGET_IMG_LDFLAGS=-Wl,-T${TARGET_IMG_LDSCRIPT}
- TARGET_IMG_LDFLAGS_AC=-Wl,-T${srcdir}/conf/${target_cpu}-${platform}-${target_os}-img-ld.sc
+ TARGET_IMG_LDFLAGS_AC=-Wl,-T${srcdir}/conf/${target_cpu}-${platform}-${host_os}-img-ld.sc
else
TARGET_IMG_LDSCRIPT=
TARGET_IMG_LDFLAGS='-Wl,-N'
@@ -215,8 +213,8 @@ AC_MSG_RESULT([$TARGET_IMG_LDFLAGS_AC])
# For platforms where ELF is not the default link format.
AC_MSG_CHECKING([for command to convert module to ELF format])
-case ${host_os}:${target_os} in
- cygwin:cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
+case ${host_os} in
+ cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
*) ;;
esac
AC_SUBST(TARGET_OBJ2ELF)
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
