[PATCH] binutils-2.16.90.0.3: can't compile 2.4.30

[PATCH] binutils-2.16.90.0.3: can't compile 2.4.30

[Herbert Rosmanith]

good evening,

updating to binutils 2.16.90.0.3 today resulting in being unable
to compile 2.4.30. as it turns out, it's an assembly problem.
please accept these two patches:

(1)

# diff -uN linux-2.4.30/arch/i386/kernel/process.c linux-2.4.30.rescue/arch/i386/kernel/process.c
--- linux-2.4.30/arch/i386/kernel/process.c     Wed Nov 17 12:54:21 2004
+++ linux-2.4.30.rescue/arch/i386/kernel/process.c      Sat May 21 22:11:58 2005
@@ -5,6 +5,8 @@
  *
  *  Pentium III FXSR, SSE support
  *     Gareth Hughes <gareth@valinux.com>, May 2000
+ * Sat May 21 22:11:22 MEST 2005 herp - Herbert Rosmanith
+ *      minor fixes for as from binutils-2.16
  */
 
 /*
@@ -544,7 +546,7 @@
  * Save a segment.
  */
 #define savesegment(seg,value) \
-       asm volatile("movl %%" #seg ",%0":"=m" (*(int *)&(value)))
+       asm volatile("movw %%" #seg ",%0":"=m" (*(int *)&(value)))
 
 int copy_thread(int nr, unsigned long clone_flags, unsigned long esp,
        unsigned long unused,
@@ -661,8 +663,8 @@
         * Save away %fs and %gs. No need to save %es and %ds, as
         * those are always kernel segments while inside the kernel.
         */
-       asm volatile("movl %%fs,%0":"=m" (*(int *)&prev->fs));
-       asm volatile("movl %%gs,%0":"=m" (*(int *)&prev->gs));
+       asm volatile("movw %%fs,%0":"=m" (*(int *)&prev->fs));
+       asm volatile("movw %%gs,%0":"=m" (*(int *)&prev->gs));
 
        /*
         * Restore %fs and %gs.


(2)

--- linux-2.4.30/include/asm-i386/system.h      Fri May 20 03:41:56 2005
+++ linux-2.4.30.rescue/include/asm-i386/system.h       Sat May 21 22:07:10 2005
@@ -84,7 +84,7 @@
 #define loadsegment(seg,value)                 \
        asm volatile("\n"                       \
                "1:\t"                          \
-               "movl %0,%%" #seg "\n"          \
+               "movw %0,%%" #seg "\n"          \
                "2:\n"                          \
                ".section .fixup,\"ax\"\n"      \
                "3:\t"                          \


---

long explanation follows.


I just updated binutils to 2.16.90.0.3. when compiling 2.4.30, I get
the following error:

gcc -D__KERNEL__ -I/data/root/linux-2.4.30.rescue/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
-fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i586
-nostdinc -iwithprefix include -DKBUILD_BASENAME=process  -c -o
process.o process.c
{standard input}: Assembler messages:
{standard input}:738: Error: suffix or operands invalid for `mov'
{standard input}:739: Error: suffix or operands invalid for `mov'
{standard input}:832: Error: suffix or operands invalid for `mov'
{standard input}:833: Error: suffix or operands invalid for `mov'
{standard input}:884: Error: suffix or operands invalid for `mov'
{standard input}:885: Error: suffix or operands invalid for `mov'
{standard input}:887: Error: suffix or operands invalid for `mov'
{standard input}:899: Error: suffix or operands invalid for `mov'
make[1]: *** [process.o] Error 1

If we look at the assembly code:

   715  .globl copy_thread
   716          .type    copy_thread,@function
   717  copy_thread:
...
   737  #APP
   738          movl %fs,636(%ebx)
   739          movl %gs,640(%ebx)


then it is clear that a movl on a segreg should really be a movw.
(same error in 832, 833 and so on: movl vs. movw)

*but* ... why is this code generated in the first place? is this
a compiler problem? I'm using gss-2.95.3. copy_thread() doesn have
any asm() statement, hm, but then ... *ponder*

ok, the two line are possibly generated by this one:

   549  int copy_thread(int nr, unsigned long clone_flags, unsigned long esp,

   564
   565          savesegment(fs,p->thread.fs);
   566          savesegment(gs,p->thread.gs);


ok, I think this is the source of the error:

   546  #define savesegment(seg,value) \
   547          asm volatile("movl %%" #seg ",%0":"=m" (*(int *)&(value)))
   548


this definitely should be a movw, right?

best regards,
h.rosmanith

Re: [PATCH] binutils-2.16.90.0.3: can't compile 2.4.30

[Alessandro Suardi]

http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch

On 5/21/05, Herbert Rosmanith <kernel@wildsau.enemy.org> wrote:
> 
> 
> good evening,
> 
> updating to binutils 2.16.90.0.3 today resulting in being unable
> to compile 2.4.30. as it turns out, it's an assembly problem.

Hi Herbert,

  this seems to be documented in the binutils release notes, which
  will point you to this:

http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch

> please accept these two patches:
> 
> (1)
> 
> # diff -uN linux-2.4.30/arch/i386/kernel/process.c linux-2.4.30.rescue/arch/i386/kernel/process.c
> --- linux-2.4.30/arch/i386/kernel/process.c     Wed Nov 17 12:54:21 2004
> +++ linux-2.4.30.rescue/arch/i386/kernel/process.c      Sat May 21 22:11:58 2005
> @@ -5,6 +5,8 @@
>   *
>   *  Pentium III FXSR, SSE support
>   *     Gareth Hughes <gareth@valinux.com>, May 2000
> + * Sat May 21 22:11:22 MEST 2005 herp - Herbert Rosmanith
> + *      minor fixes for as from binutils-2.16
>   */
> 
>  /*
> @@ -544,7 +546,7 @@
>   * Save a segment.
>   */
>  #define savesegment(seg,value) \
> -       asm volatile("movl %%" #seg ",%0":"=m" (*(int *)&(value)))
> +       asm volatile("movw %%" #seg ",%0":"=m" (*(int *)&(value)))
> 
>  int copy_thread(int nr, unsigned long clone_flags, unsigned long esp,
>         unsigned long unused,
> @@ -661,8 +663,8 @@
>          * Save away %fs and %gs. No need to save %es and %ds, as
>          * those are always kernel segments while inside the kernel.
>          */
> -       asm volatile("movl %%fs,%0":"=m" (*(int *)&prev->fs));
> -       asm volatile("movl %%gs,%0":"=m" (*(int *)&prev->gs));
> +       asm volatile("movw %%fs,%0":"=m" (*(int *)&prev->fs));
> +       asm volatile("movw %%gs,%0":"=m" (*(int *)&prev->gs));
> 
>         /*
>          * Restore %fs and %gs.
> 
> 
> (2)
> 
> --- linux-2.4.30/include/asm-i386/system.h      Fri May 20 03:41:56 2005
> +++ linux-2.4.30.rescue/include/asm-i386/system.h       Sat May 21 22:07:10 2005
> @@ -84,7 +84,7 @@
>  #define loadsegment(seg,value)                 \
>         asm volatile("\n"                       \
>                 "1:\t"                          \
> -               "movl %0,%%" #seg "\n"          \
> +               "movw %0,%%" #seg "\n"          \
>                 "2:\n"                          \
>                 ".section .fixup,\"ax\"\n"      \
>                 "3:\t"                          \
> 
> 
> ---
> 
> long explanation follows.
> 
> 
> I just updated binutils to 2.16.90.0.3. when compiling 2.4.30, I get
> the following error:
> 
> gcc -D__KERNEL__ -I/data/root/linux-2.4.30.rescue/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
> -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i586
> -nostdinc -iwithprefix include -DKBUILD_BASENAME=process  -c -o
> process.o process.c
> {standard input}: Assembler messages:
> {standard input}:738: Error: suffix or operands invalid for `mov'
> {standard input}:739: Error: suffix or operands invalid for `mov'
> {standard input}:832: Error: suffix or operands invalid for `mov'
> {standard input}:833: Error: suffix or operands invalid for `mov'
> {standard input}:884: Error: suffix or operands invalid for `mov'
> {standard input}:885: Error: suffix or operands invalid for `mov'
> {standard input}:887: Error: suffix or operands invalid for `mov'
> {standard input}:899: Error: suffix or operands invalid for `mov'
> make[1]: *** [process.o] Error 1
> 
> If we look at the assembly code:
> 
>    715  .globl copy_thread
>    716          .type    copy_thread,@function
>    717  copy_thread:
> ...
>    737  #APP
>    738          movl %fs,636(%ebx)
>    739          movl %gs,640(%ebx)
> 
> 
> then it is clear that a movl on a segreg should really be a movw.
> (same error in 832, 833 and so on: movl vs. movw)
> 
> *but* ... why is this code generated in the first place? is this
> a compiler problem? I'm using gss-2.95.3. copy_thread() doesn have
> any asm() statement, hm, but then ... *ponder*
> 
> ok, the two line are possibly generated by this one:
> 
>    549  int copy_thread(int nr, unsigned long clone_flags, unsigned long esp,
> 
>    564
>    565          savesegment(fs,p->thread.fs);
>    566          savesegment(gs,p->thread.gs);
> 
> 
> ok, I think this is the source of the error:
> 
>    546  #define savesegment(seg,value) \
>    547          asm volatile("movl %%" #seg ",%0":"=m" (*(int *)&(value)))
>    548
> 
> 
> this definitely should be a movw, right?
> 
> best regards,
> h.rosmanith


--alessandro

 "To love is to find your own soul
  Through the soul of the beloved one.
  When the beloved one withdraws itself from your soul
  Then you have lost your soul."

    (Edgar Lee Masters, Spoon River Anthology - "Mary McNeely")

Re: [PATCH] binutils-2.16.90.0.3: can't compile 2.4.30

[Herbert Rosmanith]

dear alessandro,

> http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch

these patches are dated from march, so they are two months old.
do you know why they still are not in the kernel? it's not right
to try to 32bit move a segment register anyway. this should be fixed,
regardless if the majority of users does not have the latest binutils.

best regards,
herbert rosmanith

Re: [PATCH] binutils-2.16.90.0.3: can't compile 2.4.30

[Herbert Rosmanith]

> it's not right to try to 32bit move a segment register anyway.

hmm ... sorry for writing without checking. it's true that
as complains. but for e.g. nasm, it's no problem at all.
e.g. if you consider this example:

bash-2.05# cat test.nasm 

bits    32
section .text

        mov     eax,ds
        mov     ds,eax

bash-2.05# nasm -f elf test.nasm 
bash-2.05# objdump -d test.o

test.o:     file format elf32-i386

Disassembly of section .text:

00000000 <.text>:
   0:   8c d8                   movl   %ds,%eax
   2:   8e d8                   movl   %eax,%ds


of course, it's still not possible to move 32 bits into a segreg,
so what? the processor will silently ignore the upper word, I guess.
(my ix86 handbook is in the office, so I can't look it up).

so, this probably means that it's *not* the linux kernel which contains
wrong code, but as from binutils-2.16 is being to restrictive when
doing sanity checking, agreed?

best regards,
herbert rosmanith

Re: [PATCH] binutils-2.16.90.0.3: can't compile 2.4.30

[Herbert Rosmanith]

> bash-2.05# cat test.nasm 
> 
> bits    32
> section .text
> 
>         mov     eax,ds
>         mov     ds,eax
 
> of course, it's still not possible to move 32 bits into a segreg,
> so what? the processor will silently ignore the upper word, I guess.

oops ... as doesn't complain about that either .... the error is produced
when moving a segreg to a 32bit memory location, e.g.:

(nasm)
        mov     ds,long [ebx]
(as)
#APP
        movl %ds,636(%ebx)
        movl %gs,640(%ebx)
#NO_APP

neither nasm nor as do like that. I wonder which code the previous
binutils produced in that case?

sorry for the superfluos posting, I really should brush up on my assembly;-)
the consequence still is to apply the patches to the kernel.

best regards,
herbert rosmanith