Current SVN is broken on x86_64

Current SVN is broken on x86_64

[Felix Zielcke]

I just tried to compile the Debian packages with the currently SVN
version and it failed:

cc -Iloader/i386/efi -I/home/fz/grub/grub2-1.96+20080804/loader/i386/efi -I. -Iinclude -I/home/fz/grub/grub2-1.96+20080804/include -Wall -W  -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes                  -Wundef -Wstrict-prototypes -g -Os -m64 -fno-stack-protector -mno-stack-arg-probe -fno-builtin -m64 -MD -c -o _linux_mod-loader_i386_efi_linux.o /home/fz/grub/grub2-1.96+20080804/loader/i386/efi/linux.c
In file included from /home/fz/grub/grub2-1.96+20080804/loader/i386/efi/linux.c:34:
/home/fz/grub/grub2-1.96+20080804/include/grub/pci.h:48:26: error: grub/cpu/pci.h: No such file or directory
/home/fz/grub/grub2-1.96+20080804/loader/i386/efi/linux.c: In function 'grub_find_video_card':
/home/fz/grub/grub2-1.96+20080804/loader/i386/efi/linux.c:471: warning: implicit declaration of function 'grub_pci_read'
make[1]: *** [_linux_mod-loader_i386_efi_linux.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory `/home/fz/grub/grub2-1.96+20080804/build/grub-efi'
make: *** [build/grub-efi] Error 2
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
debuild: fatal error at line 1319:
dpkg-buildpackage -rfakeroot -D -us -uc -j3 failed

Re: Current SVN is broken on x86_64

[Pavel Roskin]

On Mon, 2008-08-04 at 02:31 +0200, Felix Zielcke wrote:
> I just tried to compile the Debian packages with the currently SVN
> version and it failed:
> 
> cc -Iloader/i386/efi -I/home/fz/grub/grub2-1.96+20080804/loader/i386/efi -I. -Iinclude -I/home/fz/grub/grub2-1.96+20080804/include -Wall -W  -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes                  -Wundef -Wstrict-prototypes -g -Os -m64 -fno-stack-protector -mno-stack-arg-probe -fno-builtin -m64 -MD -c -o _linux_mod-loader_i386_efi_linux.o /home/fz/grub/grub2-1.96+20080804/loader/i386/efi/linux.c
> In file included from /home/fz/grub/grub2-1.96+20080804/loader/i386/efi/linux.c:34:
> /home/fz/grub/grub2-1.96+20080804/include/grub/pci.h:48:26: error: grub/cpu/pci.h: No such file or directory

I confirm it.  And the i386-pc platform grew new warnings:

kern/main.c: In function 'grub_set_root_dev':
kern/main.c:108: warning: implicit declaration of function 'grub_free'
loader/i386/pc/multiboot.c: In function 'grub_multiboot_load_elf32':
loader/i386/pc/multiboot.c:165: warning: assignment makes integer from
pointer without a cast
loader/i386/pc/multiboot.c:168: warning: passing argument 1 of
'grub_memmove' makes pointer from integer without a cast
loader/i386/pc/multiboot.c:175: warning: initialization makes pointer
from integer without a cast
loader/i386/pc/multiboot.c:177: warning: format '%p' expects type 'void
*', but argument 6 has type 'Elf32_Addr'
loader/i386/pc/multiboot.c:177: warning: format '%p' expects type 'void
*', but argument 7 has type 'Elf32_Word'
loader/i386/pc/multiboot.c:205: warning: format '%p' expects type 'void
*', but argument 5 has type 'grub_addr_t'
loader/i386/pc/multiboot.c:205: warning: format '%p' expects type 'void
*', but argument 6 has type 'grub_size_t'
loader/i386/pc/multiboot.c:205: warning: format '%p' expects type 'void
*', but argument 7 has type 'grub_uint32_t'
loader/i386/pc/multiboot.c:128: warning: unused variable
'physical_entry_addr'

-- 
Regards,
Pavel Roskin

Re: Current SVN is broken on x86_64

[Robert Millan]

On Mon, Aug 04, 2008 at 02:31:28AM +0200, Felix Zielcke wrote:
> I just tried to compile the Debian packages with the currently SVN
> version and it failed:
> 
> cc -Iloader/i386/efi -I/home/fz/grub/grub2-1.96+20080804/loader/i386/efi -I. -Iinclude -I/home/fz/grub/grub2-1.96+20080804/include -Wall -W  -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes                  -Wundef -Wstrict-prototypes -g -Os -m64 -fno-stack-protector -mno-stack-arg-probe -fno-builtin -m64 -MD -c -o _linux_mod-loader_i386_efi_linux.o /home/fz/grub/grub2-1.96+20080804/loader/i386/efi/linux.c
> In file included from /home/fz/grub/grub2-1.96+20080804/loader/i386/efi/linux.c:34:
> /home/fz/grub/grub2-1.96+20080804/include/grub/pci.h:48:26: error: grub/cpu/pci.h: No such file or directory
> /home/fz/grub/grub2-1.96+20080804/loader/i386/efi/linux.c: In function 'grub_find_video_card':
> /home/fz/grub/grub2-1.96+20080804/loader/i386/efi/linux.c:471: warning: implicit declaration of function 'grub_pci_read'

So we have grub/i386/pci.h but not grub/x86_64/pci.h.  This is my fault, but I
think it's too easy to make mistakes with this <grub/i386/> vs <grub/x86_64/>
duplicity.

Furthermore, I had a look and some of the x86_64 versions are just stubs that
include the i386 one.

Why don't we handle this like Linux?  They ship a single directory and use
#ifdefs where appropiate.  That enforces consistency in the dir layout.

-- 
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."

Re: Current SVN is broken on x86_64

[Robert Millan]

On Mon, Aug 04, 2008 at 01:02:41AM -0400, Pavel Roskin wrote:
> 
> I confirm it.  And the i386-pc platform grew new warnings:
> 
> kern/main.c: In function 'grub_set_root_dev':
> kern/main.c:108: warning: implicit declaration of function 'grub_free'
> loader/i386/pc/multiboot.c: In function 'grub_multiboot_load_elf32':
> loader/i386/pc/multiboot.c:165: warning: assignment makes integer from
> pointer without a cast
> loader/i386/pc/multiboot.c:168: warning: passing argument 1 of
> 'grub_memmove' makes pointer from integer without a cast
> loader/i386/pc/multiboot.c:175: warning: initialization makes pointer
> from integer without a cast
> loader/i386/pc/multiboot.c:177: warning: format '%p' expects type 'void
> *', but argument 6 has type 'Elf32_Addr'
> loader/i386/pc/multiboot.c:177: warning: format '%p' expects type 'void
> *', but argument 7 has type 'Elf32_Word'
> loader/i386/pc/multiboot.c:205: warning: format '%p' expects type 'void
> *', but argument 5 has type 'grub_addr_t'
> loader/i386/pc/multiboot.c:205: warning: format '%p' expects type 'void
> *', but argument 6 has type 'grub_size_t'
> loader/i386/pc/multiboot.c:205: warning: format '%p' expects type 'void
> *', but argument 7 has type 'grub_uint32_t'
> loader/i386/pc/multiboot.c:128: warning: unused variable
> 'physical_entry_addr'

Sorry, my bad.  I'll have a look at this.

-- 
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."

Re: Current SVN is broken on x86_64

[Felix Zielcke]

[-- Attachment #1: Type: text/plain, Size: 253 bytes --]

Am Montag, den 04.08.2008, 02:31 +0200 schrieb Felix Zielcke:
> I just tried to compile the Debian packages with the currently SVN
> version and it failed:
> 
Just in case it helps more, I attached the full build log now.
Uncompressed it's ~1,6 MB big-

[-- Attachment #2: buildlog.txt.bz2 --]
[-- Type: application/x-bzip, Size: 46733 bytes --]

Re: Current SVN is broken on x86_64

[Pavel Roskin]

On Mon, 2008-08-04 at 11:16 +0200, Robert Millan wrote:

> Furthermore, I had a look and some of the x86_64 versions are just stubs that
> include the i386 one.
> 
> Why don't we handle this like Linux?  They ship a single directory and use
> #ifdefs where appropiate.  That enforces consistency in the dir layout.

I think we can do it.  i386 and x86_64 could be joined into one "x86"
architecture with common headers and sources.  Perhaps the users should
still use i386 and x86_64 in configure, but the code should be mostly
common.

-- 
Regards,
Pavel Roskin

Re: Current SVN is broken on x86_64

[Robert Millan]

On Mon, Aug 04, 2008 at 08:51:25AM -0400, Pavel Roskin wrote:
> On Mon, 2008-08-04 at 11:16 +0200, Robert Millan wrote:
> 
> > Furthermore, I had a look and some of the x86_64 versions are just stubs that
> > include the i386 one.
> > 
> > Why don't we handle this like Linux?  They ship a single directory and use
> > #ifdefs where appropiate.  That enforces consistency in the dir layout.
> 
> I think we can do it.  i386 and x86_64 could be joined into one "x86"
> architecture with common headers and sources.  Perhaps the users should
> still use i386 and x86_64 in configure, but the code should be mostly
> common.

Ok, but I think the i386->x86 rename would be overkill.  We're already using
i386/ headers on x86_64 (for example, when building util/ stuff in grub-pc). It
doesn't hurt if we continue doing that IMHO.

-- 
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."

Re: Current SVN is broken on x86_64

[Pavel Roskin]

On Mon, 2008-08-04 at 17:11 +0200, Robert Millan wrote:

> Ok, but I think the i386->x86 rename would be overkill.  We're already using
> i386/ headers on x86_64 (for example, when building util/ stuff in grub-pc). It
> doesn't hurt if we continue doing that IMHO.

Fine with me.

-- 
Regards,
Pavel Roskin

Current SVN is (still ?, again ?) broken

[Felix Zielcke]

Am Montag, den 04.08.2008, 02:31 +0200 schrieb Felix Zielcke:
> I just tried to compile the Debian packages with the currently SVN
> version and it failed:
> 
And again, I did a clean `svn co' to compile the full suite of debian
packages and this time i386-efi failed:

cc -Ikern/i386/efi -I/home/fz/grub/grub2-1.96+20080807/kern/i386/efi -I. -Iinclude -I/home/fz/grub/grub2-1.96+20080807/include -Wall -W  -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes -Wundef -Wstrict-prototypes -g -Os -m64 -fno-stack-protector -mno-stack-arg-probe -fno-builtin -m64 -MD -c -o kernel_mod-kern_i386_efi_init.o /home/fz/grub/grub2-1.96+20080807/kern/i386/efi/init.c
/home/fz/grub/grub2-1.96+20080807/kern/i386/efi/init.c:28:26: error: grub/cpu/tsc.h: No such file or directory
/home/fz/grub/grub2-1.96+20080807/kern/i386/efi/init.c: In function 'grub_machine_init':
/home/fz/grub/grub2-1.96+20080807/kern/i386/efi/init.c:34: warning: implicit declaration of function 'grub_tsc_init'
make[1]: *** [kernel_mod-kern_i386_efi_init.o] Error 1

Re: Current SVN is (still ?, again ?) broken

[Bean]

On Thu, Aug 7, 2008 at 6:58 PM, Felix Zielcke <fzielcke@z-51.de> wrote:
> Am Montag, den 04.08.2008, 02:31 +0200 schrieb Felix Zielcke:
>> I just tried to compile the Debian packages with the currently SVN
>> version and it failed:
>>
> And again, I did a clean `svn co' to compile the full suite of debian
> packages and this time i386-efi failed:
>
> cc -Ikern/i386/efi -I/home/fz/grub/grub2-1.96+20080807/kern/i386/efi -I. -Iinclude -I/home/fz/grub/grub2-1.96+20080807/include -Wall -W  -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes -Wundef -Wstrict-prototypes -g -Os -m64 -fno-stack-protector -mno-stack-arg-probe -fno-builtin -m64 -MD -c -o kernel_mod-kern_i386_efi_init.o /home/fz/grub/grub2-1.96+20080807/kern/i386/efi/init.c
> /home/fz/grub/grub2-1.96+20080807/kern/i386/efi/init.c:28:26: error: grub/cpu/tsc.h: No such file or directory
> /home/fz/grub/grub2-1.96+20080807/kern/i386/efi/init.c: In function 'grub_machine_init':
> /home/fz/grub/grub2-1.96+20080807/kern/i386/efi/init.c:34: warning: implicit declaration of function 'grub_tsc_init'
> make[1]: *** [kernel_mod-kern_i386_efi_init.o] Error 1

Hi,

I have fixed missing file in build script i386-efi.rmk and
i386-ieee1275.rmk, it should work now. x86_64-efi.rmk is still broken,
I will take a look at it later.

But I don't have 32-bit efi hardware to test, would someone please
verify that if the new tsc code work in efi ?

-- 
Bean

merging i386-efi and x86_64-efi (Re: Current SVN is broken on x86_64)

[Robert Millan]

[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]

On Mon, Aug 04, 2008 at 08:51:25AM -0400, Pavel Roskin wrote:
> On Mon, 2008-08-04 at 11:16 +0200, Robert Millan wrote:
> 
> > Furthermore, I had a look and some of the x86_64 versions are just stubs that
> > include the i386 one.
> > 
> > Why don't we handle this like Linux?  They ship a single directory and use
> > #ifdefs where appropiate.  That enforces consistency in the dir layout.
> 
> I think we can do it.  i386 and x86_64 could be joined into one "x86"
> architecture with common headers and sources.  Perhaps the users should
> still use i386 and x86_64 in configure, but the code should be mostly
> common.

I gave a try at this, which I haven't completed yet.  Here's what I have
so far.

The biggest stumbling block seems to be that autoconf doesn't make it easy
to do AC_CHECK_SIZEOF checks for standard compiling and cross-compiling in
the same run (it does support cross-compiling though).

I haven't found a way to do it.  If I modify types.m4 to export its
findings to a variable instead of dumping them to config.h directly,
further calls to the same check won't return different results, even if
CC / CFLAGS has been adjusted.

-- 
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."

[-- Attachment #2: efi_build.diff --]
[-- Type: text/x-diff, Size: 3033 bytes --]

Index: conf/i386-efi.rmk
===================================================================
--- conf/i386-efi.rmk	(revision 1787)
+++ conf/i386-efi.rmk	(working copy)
@@ -1,8 +1,8 @@
 # -*- makefile -*-
 
-COMMON_ASFLAGS = -nostdinc -fno-builtin -m32
-COMMON_CFLAGS = -fno-builtin -m32
-COMMON_LDFLAGS = -melf_i386 -nostdlib
+COMMON_ASFLAGS = -nostdinc -fno-builtin
+COMMON_CFLAGS = -fno-builtin
+COMMON_LDFLAGS = -nostdlib
 
 # Used by various components.  These rules need to precede them.
 normal/lexer.c_DEPENDENCIES = grub_script.tab.h
Index: configure.ac
===================================================================
--- configure.ac	(revision 1787)
+++ configure.ac	(working copy)
@@ -75,7 +75,6 @@
 # Adjust CPU unless target was explicitly specified.
 if test -z "$target_alias"; then
   case "$target_cpu"-"$platform" in
-    x86_64-efi) ;;
     x86_64-*) target_cpu=i386 ;;
     powerpc64-ieee1275) target_cpu=powerpc ;;
   esac
@@ -84,21 +83,15 @@
 # Check if the platform is supported, make final adjustments.
 case "$target_cpu"-"$platform" in
   i386-efi) ;;
-  x86_64-efi) ;;
-  i386-pc) ;;
-  i386-coreboot) ;;
-  i386-linuxbios) platform=coreboot ;;
-  i386-ieee1275) ;;
+  i386-pc)		target_m32=1 ;;
+  i386-coreboot)	target_m32=1 ;;
+  i386-linuxbios)	target_m32=1 ; platform=coreboot ;;
+  i386-ieee1275)	target_m32=1 ;;
   powerpc-ieee1275) ;;
   sparc64-ieee1275) ;;
   *) AC_MSG_ERROR([platform "$platform" is not supported for target CPU "$target_cpu"]) ;;
 esac
 
-case "$target_cpu" in
-  i386 | powerpc) target_m32=1 ;;
-  x86_64 | sparc64) target_m64=1 ;;
-esac
-
 AC_SUBST(target_cpu)
 AC_SUBST(platform)
 
Index: include/grub/i386/setjmp.h
===================================================================
--- include/grub/i386/setjmp.h	(revision 1787)
+++ include/grub/i386/setjmp.h	(working copy)
@@ -19,10 +19,19 @@
 #ifndef GRUB_SETJMP_CPU_HEADER
 #define GRUB_SETJMP_CPU_HEADER	1
 
-typedef unsigned long grub_jmp_buf[6];
+typedef unsigned long grub_jmp_buf[8];
 
+#ifdef __x86_64__
+
+int grub_setjmp (grub_jmp_buf env);
+void grub_longjmp (grub_jmp_buf env, int val) __attribute__ ((noreturn));
+
+#else
+
 int grub_setjmp (grub_jmp_buf env) __attribute__ ((cdecl, regparm (3)));
 void grub_longjmp (grub_jmp_buf env, int val) __attribute__ ((noreturn, cdecl,
 							      regparm (3)));
 
+#endif
+
 #endif /* ! GRUB_SETJMP_CPU_HEADER */
Index: include/grub/i386/types.h
===================================================================
--- include/grub/i386/types.h	(revision 1787)
+++ include/grub/i386/types.h	(working copy)
@@ -19,12 +19,24 @@
 #ifndef GRUB_TYPES_CPU_HEADER
 #define GRUB_TYPES_CPU_HEADER	1
 
+#ifdef __i386__
+
 /* The size of void *.  */
 #define GRUB_TARGET_SIZEOF_VOID_P	4
 
 /* The size of long.  */
 #define GRUB_TARGET_SIZEOF_LONG		4
 
+#else
+
+/* The size of void *.  */
+#define GRUB_TARGET_SIZEOF_VOID_P	8
+
+/* The size of long.  */
+#define GRUB_TARGET_SIZEOF_LONG		8
+
+#endif
+
 /* i386 is little-endian.  */
 #undef GRUB_TARGET_WORDS_BIGENDIAN
 

Re: merging i386-efi and x86_64-efi (Re: Current SVN is broken on x86_64)

[Robert Millan]

On Thu, Aug 07, 2008 at 02:21:03PM +0200, Robert Millan wrote:
> On Mon, Aug 04, 2008 at 08:51:25AM -0400, Pavel Roskin wrote:
> > On Mon, 2008-08-04 at 11:16 +0200, Robert Millan wrote:
> > 
> > > Furthermore, I had a look and some of the x86_64 versions are just stubs that
> > > include the i386 one.
> > > 
> > > Why don't we handle this like Linux?  They ship a single directory and use
> > > #ifdefs where appropiate.  That enforces consistency in the dir layout.
> > 
> > I think we can do it.  i386 and x86_64 could be joined into one "x86"
> > architecture with common headers and sources.  Perhaps the users should
> > still use i386 and x86_64 in configure, but the code should be mostly
> > common.
> 
> I gave a try at this, which I haven't completed yet.  Here's what I have
> so far.
> 
> The biggest stumbling block seems to be that autoconf doesn't make it easy
> to do AC_CHECK_SIZEOF checks for standard compiling and cross-compiling in
> the same run (it does support cross-compiling though).
> 
> I haven't found a way to do it.  If I modify types.m4 to export its
> findings to a variable instead of dumping them to config.h directly,
> further calls to the same check won't return different results, even if
> CC / CFLAGS has been adjusted.

Somebody pointed an interesting solution to me on IRC:  we could have multiple
configure scripts, one for each kind of compilation.

I think what would fit well in this scheme is a simple util/configure that
just setups things to build native tools "the usual way", and then the main
configure can:

  a) Invoke util/configure with the right params for native compilation

  b) Simplify its own arch handling logic.

Thoughts?

-- 
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."