2005-05-21 20:18:46

by K. Ernel

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



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 <[email protected]>, 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




2005-05-22 11:08:16

by Alessandro Suardi

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

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

On 5/21/05, Herbert Rosmanith <[email protected]> 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 <[email protected]>, 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")

2005-05-22 11:21:14

by K. Ernel

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

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

2005-05-23 11:14:16

by K. Ernel

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


> 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

2005-05-23 11:25:41

by K. Ernel

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

> 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