[PATCH] new patch for amd64

[PATCH] new patch for amd64

[Ruslan Nikolaev]

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

Hi all!

I have seen another patch for amd64 by Marco Gerards. In fact month ago I sent the patch that also allows compiling on x86_64.
 
By the way I decided to send new patch (it's really works with amd64).
 
Some bugs was fixed:
- it doesn't break x86 compiling now (small bug)
- it allows you to compile grub even you haven't libc32 and other 32-bit libraries and OS doesn't support executing 32-bit binaries. Of course -m32 gcc param is always available. But as you can see you also can't check regparm=3 bug in this case :( That is why for x86_64 always using regparm=2 for nested functions in this patch.
 
!!! PLEASE NOTE THAT IT'S NOT REAL NEED TO DO SPECIAL AMD64 VERSION BECAUSE USER CAN CHOOSE TO LOAD 32-bit operating system under x86_64. Moreover you can't switch to 64-bit by bootloader because you need enable paging first (that is not very clear to do by bootloader).
 
NEW PATCH:
 
diff -urN old/configure.ac new/configure.ac
--- old/configure.ac 2005-09-11 11:07:36.000000000 +0400
+++ new/configure.ac 2005-09-11 11:19:36.000000000 +0400
@@ -22,6 +22,7 @@
 
 case "$host_cpu" in
   i[[3456]]86) host_cpu=i386 ;;
+  x86_64) ;;
   powerpc) ;;
   sparc64) ;;
   *) AC_MSG_ERROR([unsupported CPU type]) ;;
@@ -29,6 +30,7 @@
 
 case "$host_cpu"-"$host_vendor" in
   i386-*) host_vendor=pc ;;
+  x86_64-*) host_vendor=pc ;;
   powerpc-*) host_vendor=ieee1275 ;;
   sparc64-*) host_vendor=ieee1275 ;;
   *) AC_MSG_ERROR([unsupported machine type]) ;;
@@ -64,8 +66,8 @@
     tmp_CFLAGS="$tmp_CFLAGS -O2 -fno-strength-reduce -fno-unroll-loops"
   fi
 
-  # Force no alignment to save space on i386.
-  if test "x$host_cpu" = xi386; then
+  # Force no alignment to save space on i386/x86_64.
+  if test "x$host_cpu" = xi386 -o "x$host_cpu" = xx86_64; then
     AC_CACHE_CHECK([whether -falign-loops works], [falign_loop_flag], [
       CFLAGS="-falign-loops=1"
       AC_TRY_COMPILE(, , [falign_loop_flag=yes], [falign_loop_flag=no])
@@ -84,21 +86,35 @@
 
 # Defined in aclocal.m4.
 grub_ASM_USCORE
-if test "x$host_cpu" = xi386; then
+if test "x$host_cpu" = xi386 -o "x$host_cpu" = xx86_64; then
   grub_CHECK_START_SYMBOL
   grub_CHECK_BSS_START_SYMBOL
   grub_CHECK_END_SYMBOL
 fi
 
-if test "x$host_cpu" = xi386; then
+if test "x$host_cpu" = xi386 -o "x$host_cpu" = xx86_64; then
   grub_I386_ASM_PREFIX_REQUIREMENT
   grub_I386_ASM_ADDR32
   grub_I386_ASM_ABSOLUTE_WITHOUT_ASTERISK
-  grub_I386_CHECK_REGPARM_BUG
+  # There is no clean decision how to detect regparm=3 bug on x86_64
+  if test "x$host_cpu" = xi386; then
+    grub_I386_CHECK_REGPARM_BUG
+  else
+    AC_DEFINE([NESTED_FUNC_ATTR], [__attribute__ ((__regparm__ (2)))], [Catch gcc bug])
+  fi
 else
   AC_DEFINE([NESTED_FUNC_ATTR], [], [Catch gcc bug])
 fi
 
+# Keep CC for BUILD_CC
+CC_ARCH="$CC"
+
+# Override x86_64 settings
+if test "x$host_cpu" = xx86_64; then
+  CC="$CC -m32"
+  LD="ld -melf_i386"
+fi
+
 AC_PROG_INSTALL
 AC_PROG_MAKE_SET
 AC_CHECK_TOOL(OBJCOPY, objcopy)
@@ -115,7 +131,7 @@
   AC_CHECK_PROGS(BUILD_CC, [gcc egcs cc],
    [AC_MSG_ERROR([none of gcc, egcs and cc is found. set BUILD_CC manually.])])
 else
-  BUILD_CC="$CC"
+  BUILD_CC="$CC_ARCH"
   AC_SUBST(BUILD_CC)
 fi
 
@@ -132,8 +148,8 @@
 AC_CHECK_SIZEOF(void *)
 AC_CHECK_SIZEOF(long)
 
-# Check LZO when compiling for the i386.
-if test "x$host_cpu" = xi386; then
+# Check LZO when compiling for the i386/x86_64.
+if test "x$host_cpu" = xi386 -o "x$host_cpu" = xx86_64; then
   # There are three possibilities. LZO version 2 installed with the name
   # liblzo2, with the name liblzo, and LZO version 1.
   AC_CHECK_LIB(lzo2, __lzo_init_v2, [LIBLZO="-llzo2"],
@@ -161,6 +177,13 @@
 CFLAGS="$tmp_CFLAGS"
 CPPFLAGS="$tmp_CPPFLAGS"
 
+# Create links for x86_64
+if test "x$host_cpu" = xx86_64; then
+  AC_CONFIG_LINKS([include/grub/x86_64:include/grub/i386
+ conf/x86_64-$host_vendor.mk:conf/i386-$host_vendor.mk
+ conf/x86_64-$host_vendor.rmk:conf/i386-$host_vendor.rmk])
+fi
+
 # Output files.
 AC_CONFIG_LINKS([include/grub/cpu:include/grub/$host_cpu
  include/grub/machine:include/grub/$host_cpu/$host_vendor])
 

		
---------------------------------
Yahoo! for Good
 Click here to donate to the Hurricane Katrina relief effort. 

[-- Attachment #2: Type: text/html, Size: 5458 bytes --]

Re: [PATCH] new patch for amd64

[Yoshinori K. Okuji]

On Wednesday 21 September 2005 01:10 am, Ruslan Nikolaev wrote:
> I have seen another patch for amd64 by Marco Gerards. In fact month ago I
> sent the patch that also allows compiling on x86_64.

I have no idea which patch is better, so please decide it with Marco.

However, your assignment is not finished, right? How much time does it take?

Okuji

Re: [PATCH] new patch for amd64

[Marco Gerards]

Ruslan Nikolaev <nruslan_devel@yahoo.com> writes:

Hi Ruslan,

> I have seen another patch for amd64 by Marco Gerards. In fact month
> ago I sent the patch that also allows compiling on x86_64.

Right, I sent in this new patch because I don't like changing LD and
CC the way you do and because there were many special cases.  I had a
look how to change this and by the time I figured out a clean way, I
already had a new patch.  Hopefully you do not feel ignored (perhaps I
should've replied to your patch with this one as an alternative or
so...), that was not my intention.  You could say I was inspired to
fix AMD64 compilation this way because of your patch.

> By the way I decided to send new patch (it's really works with amd64).
>  
> Some bugs was fixed: - it doesn't break x86 compiling now (small bug)
> - it allows you to compile grub even you haven't libc32 and other
> 32-bit libraries and OS doesn't support executing 32-bit binaries. Of
> course -m32 gcc param is always available. But as you can see you also
> can't check regparm=3 bug in this case :( That is why for x86_64
> always using regparm=2 for nested functions in this patch.

Why can't you test for the regparam=3 bug?

> !!! PLEASE NOTE THAT IT'S NOT REAL NEED TO DO SPECIAL AMD64 VERSION
> BECAUSE USER CAN CHOOSE TO LOAD 32-bit operating system under
> x86_64. Moreover you can't switch to 64-bit by bootloader because you
> need enable paging first (that is not very clear to do by bootloader).

Right.  My patch is not 64 bits either.  What I would prefer is
applying my patch because it does not change that much and doesn't
require much special cases and it is a bit better readable (that's why
I sent it in basically).

After that I could have a look at your other patch.  But I prefer to
wait until Guillem sent in his patch for 64 bits ELF support.  If that
patch is applied we could change Ruslan's patch to use that code,
but if it takes too long Ruslan's patch can be applied first.

But I am not sure if we want a 64 bits multiboot and what is involved
with changing multiboot that way.  I leave that to Okuji.

Thanks,
Marco

Re: 2Marco Gerards

[Ruslan Nikolaev]

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

> Why can't you test for the regparam=3 bug?
 
Because it requires to build 32-bit file. As I said before this patch will work even the OS can't load 32-bit executables at all. I'm not sure about compiling it as a 64-bit file because it generates another code; moreover x86_64 accepts regparam=6. Perhaps it would detect bug... but who knows?
 
> ...
> But I am not sure if we want a 64 bits multiboot and what is involved
> with changing multiboot that way. I leave that to Okuji.
 
I can't understand what you mean. If it is support for ELF64 multiboot then it already presents in GRUB (see multiboot.c file).
If it is ELF64 multiboot & switching to 64-bit mode then it is MISTAKE because it requires enabling paging and it's not clear at all.
If it is 64-bit version of GRUB utilities then my patch already provides it
 

		
---------------------------------
Yahoo! for Good
 Click here to donate to the Hurricane Katrina relief effort. 

[-- Attachment #2: Type: text/html, Size: 1179 bytes --]

Re: 2Yoshinori K. Okuji

[Ruslan Nikolaev]

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

> I have no idea which patch is better, so please decide it with Marco.

I also can't say what is better. However my patch already works perfectly on my x86_64 machine with Linux w/o 32-bit binaries support. All compiled utilities are 64-bit. Chainloading, multiboot and linux loading working. The patch is smaller and very simple. It also doesn't change build system just for x86_64.
 
> However, your assignment is not finished, right? How much time does it take?
I hope it will be soon. But who knows...
This is a very small patch; I can write "copyright disclaimer" if it would be easily... Does it requires any signs on real papers?

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[-- Attachment #2: Type: text/html, Size: 892 bytes --]

Re: 2Marco Gerards (new)

[Ruslan Nikolaev]

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

2Marco Gerards
 
My mistake. Please read first line as "Because it requires to load 32-bit file..."

Ruslan Nikolaev <nruslan_devel@yahoo.com> wrote:
> Why can't you test for the regparam=3 bug?
 
Because it requires to build 32-bit file. As I said before this patch will work even the OS can't load 32-bit executables at all. I'm not sure about compiling it as a 64-bit file because it generates another code; moreover x86_64 accepts regparam=6. Perhaps it would detect bug... but who knows?
 
> ...
> But I am not sure if we want a 64 bits multiboot and what is involved
> with changing multiboot that way. I leave that to Okuji.
 
I can't understand what you mean. If it is support for ELF64 multiboot then it already presents in GRUB (see multiboot.c file).
If it is ELF64 multiboot & switching to 64-bit mode then it is MISTAKE because it requires enabling paging and it's not clear at all.
If it is 64-bit version of GRUB utilities then my patch already provides it
 


---------------------------------
Yahoo! for Good
Click here to donate to the Hurricane Katrina relief effort. _______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[-- Attachment #2: Type: text/html, Size: 1822 bytes --]

Re: 2Marco Gerards (new)

[Marco Gerards]

Ruslan Nikolaev <nruslan_devel@yahoo.com> writes:

Hi Ruslan,

> Because it requires to build 32-bit file. As I said before this patch
> will work even the OS can't load 32-bit executables at all. I'm not
> sure about compiling it as a 64-bit file because it generates another
> code; moreover x86_64 accepts regparam=6. Perhaps it would detect
> bug... but who knows?

Well, right.  If we can't test it, we should just assume the worst
case scenario.  That means we should assume the bug is there if we can
not test for it.

I can make this change and will commit my patch tomorrow.  Any further
improvements from that point on are more than welcome.  For me it is
just important that CVS works because I have some GRUB 2 trees here
that I want to test and all don't compile so it is making progress
from my side slow...

>> ...  But I am not sure if we want a 64 bits multiboot and what is
>> involved with changing multiboot that way. I leave that to Okuji.
>  
> I can't understand what you mean. If it is support for ELF64 multiboot
> then it already presents in GRUB (see multiboot.c file).  If it is
> ELF64 multiboot & switching to 64-bit mode then it is MISTAKE because
> it requires enabling paging and it's not clear at all.  If it is
> 64-bit version of GRUB utilities then my patch already provides it

What I mean is that multiboot is a standard.  I think we can not
modify GRUB without modifying the standard.  But perhaps I am just
mistaken because I do not know enough about the subject.

--
Marco

Re: 2Marco Gerards (important info)

[Ruslan Nikolaev]

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

Just want to inform you about other problems.
 
Please note that all other testings (expect for OBJCOPY) during configure _MUST_ BE DONE in 64-bit mode compiling. Otherwise I had problems with Linux w/o 32-bit support (there are problems with building because I haven't 32-bit libraries and so on).
 
OBJCOPY test can be done in 32-bit mode compiling. Otherwise i386 test will fail. There is no problems. It compiles properly in 32-bit mode even if you haven't 32-bit libraries.
 
FOR MORE INFO SEE MY PATCH. IT OVERRIDES CC and keep original value in CC_ARCH (for building utilities as 64-bit files) !!!!!!! AFTER ALL TESTINGS EXPECT "OBJCOPY test".
 
!!!!! It's really too hard to make patch without saving and restoring CC and LD because you also need to make configure tests for x86_64 separately and more routine works.
That is why my patch just overrides settings and then restores settings for building utilities.
 

		
---------------------------------
Yahoo! for Good
 Click here to donate to the Hurricane Katrina relief effort. 

[-- Attachment #2: Type: text/html, Size: 1238 bytes --]

Re: 2Marco Gerards (important info)

[Marco Gerards]

Ruslan Nikolaev <nruslan_devel@yahoo.com> writes:

> Just want to inform you about other problems.
>  
> Please note that all other testings (expect for OBJCOPY) during
> configure _MUST_ BE DONE in 64-bit mode compiling. Otherwise I had
> problems with Linux w/o 32-bit support (there are problems with
> building because I haven't 32-bit libraries and so on).
>  
> OBJCOPY test can be done in 32-bit mode compiling. Otherwise i386 test
> will fail. There is no problems. It compiles properly in 32-bit mode
> even if you haven't 32-bit libraries.
>  
> FOR MORE INFO SEE MY PATCH. IT OVERRIDES CC and keep original value in
> CC_ARCH (for building utilities as 64-bit files) !!!!!!! AFTER ALL
> TESTINGS EXPECT "OBJCOPY test".

Most tests just test if it compiles.  AFAIK only the REGPARAM_BUG test
checks if it runs.  We can test for that.  But this is a bug not just
related to the AMD64, it is also the case when cross-compiling, I
think?  So this bug already exists, this is just one scenario that
triggers this bug, right?

> !!!!! It's really too hard to make patch without saving and restoring
> CC and LD because you also need to make configure tests for x86_64
> separately and more routine works.  That is why my patch just
> overrides settings and then restores settings for building utilities.

I am not sure about that yet.

I will check in my patch later this evening.  After that I will have a
look at the REGPARAM issue.  I will try to test if it will build on a
system without 32 bits libraries installed.

--
Marco

Re: 2Marco Gerards (answer)

[Ruslan Nikolaev]

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

The problem that is related with REGPARAM test:
 
During configuring the test of regparm bug will be compiled and then executed.
First:
it can't properly compiled if you haven't 32-bit libraries
Second:
it can't be executed if system can't execute 32-bit executables
Third:
you can't compile this test as 64-bit because it generates another code and you can't be 100% that bug was found.
 
The problems with other tests:
 
These test (expect OBJCOPY test) will not fail if compiler works in 32-bit mode & you have 32-bit libraries & system can execute 32-bit files. BUT it will fail otherwise. In that case we _must_ execute these tests (expect OBJCOPY test) in 64-bit mode compiling. OBJCOPY will not fail in 32-bit mode even you haven't 32-bit libraries (in 64-bit mode OBJCOPY test will fail).

I don't know how it will be for you but at least I described the problems that I had.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[-- Attachment #2: Type: text/html, Size: 1233 bytes --]