2.6.1-mm2: compiler warning

Compiling the kernel under 2.6.1-mm2, gcc-3.3.2 (same messages as under 2.6.1-rc1-mm1, re-tested),

arch/i386/boot/setup.S: Assembler messages:
arch/i386/boot/setup.S:165: Warning: value 0x37ffffff truncated to 0x37ffffff

Quoted 5 lines · Mario Vanoni

Compiling the kernel under 2.6.1-mm2, gcc-3.3.2 (same messages as under 2.6.1-rc1-mm1, re-tested),

arch/i386/boot/setup.S: Assembler messages:
arch/i386/boot/setup.S:165: Warning: value 0x37ffffff truncated to 0x37ffffff

This is apparently a known problem and has existed for a long time, but no-one has fixed it for some reason. I asked the exacly same question a few months ago, and someone told me that this issue has been around forever, but is noticed under 2.6, since it is less verbose during the compilation. I'll pass the message that was told to me: If you've got a fix, it would surely be included in the kernel.

Quoted 9 lines · Tim Cambrant

Quoted 6 lines · Mario Vanoni

Compiling the kernel under 2.6.1-mm2, gcc-3.3.2 (same messages as under 2.6.1-rc1-mm1, re-tested),

arch/i386/boot/setup.S: Assembler messages:
arch/i386/boot/setup.S:165: Warning: value 0x37ffffff truncated to 0x37ffffff

Quoted 6 lines

This is apparently a known problem and has existed for a long time, but no-one has fixed it for some reason. I asked the exacly same question a few months ago, and someone told me that this issue has been around forever, but is noticed under 2.6, since it is less verbose during the compilation. I'll pass the message that was told to me: If you've got a fix, it would surely be included in the kernel.

The problem is in the MAXMEM macro. This macro takes the inverse of a positive number, subtracts another number, and the negative result overflows the negative range of a 32-bit integer. The assembler truncates it, but apparently it can't print overly negative numbers correctly, that's why it looks so strange.

My proposed fix is attached: change the macro to subtract the numbers from 0xFFFFFFFF, and then add 1 at the end. That yields the same result, but without going through a negative intermediate value that needs to be truncated.

-- Bart

Quoted 29 lines · Bart Samwel

Quoted 9 lines · Tim Cambrant

Quoted 5 lines · Mario Vanoni

Compiling the kernel under 2.6.1-mm2, gcc-3.3.2 (same messages as under 2.6.1-rc1-mm1, re-tested),

arch/i386/boot/setup.S: Assembler messages:
arch/i386/boot/setup.S:165: Warning: value 0x37ffffff truncated to 0x37ffffff

Quoted 6 lines

This is apparently a known problem and has existed for a long time, but no-one has fixed it for some reason. I asked the exacly same question a few months ago, and someone told me that this issue has been around forever, but is noticed under 2.6, since it is less verbose during the compilation. I'll pass the message that was told to me: If you've got a fix, it would surely be included in the kernel.

The problem is in the MAXMEM macro. This macro takes the inverse of a positive number, subtracts another number, and the negative result overflows the negative range of a 32-bit integer. The assembler truncates it, but apparently it can't print overly negative numbers correctly, that's why it looks so strange.

My proposed fix is attached: change the macro to subtract the numbers from 0xFFFFFFFF, and then add 1 at the end. That yields the same result, but without going through a negative intermediate value that needs to be truncated.

-- Bart

page.h line 126

Quoted 5 lines

page.h renamed from page.h.orig +1 -1

@@ -123,7 +123,7 @@
 
 #define PAGE_OFFSET		((unsigned long)__PAGE_OFFSET)
 #define VMALLOC_RESERVE		((unsigned long)__VMALLOC_RESERVE)
-#define MAXMEM			(-__PAGE_OFFSET-__VMALLOC_RESERVE)
+#define MAXMEM			(0xFFFFFFFF-__PAGE_OFFSET-__VMALLOC_RESERVE+1)

Try:

#define MAXMEM (~__PAGE_OFFSET + 1 - __VMALLOC_RESERVE)

Quoted 12 lines

page.h line 126

Quoted 8 lines

page.h renamed from page.h.orig +1 -1

@@ -123,7 +123,7 @@
 
 #define PAGE_OFFSET		((unsigned long)__PAGE_OFFSET)
 #define VMALLOC_RESERVE		((unsigned long)__VMALLOC_RESERVE)
-#define MAXMEM			(-__PAGE_OFFSET-__VMALLOC_RESERVE)
+#define MAXMEM			(0xFFFFFFFF-__PAGE_OFFSET-__VMALLOC_RESERVE+1)

Try:

Quoted 1 line

#define MAXMEM (~__PAGE_OFFSET + 1 - __VMALLOC_RESERVE)

I tried that first, before I came up with the solution in the patch, because I didn't like the dependency of 0xFFFFFFFF being 32-bit. It was a nice idea, but it didn't work. Apparently, gas interprets ~ as a one's complement negation operator, not a bitwise or. Therefore, ~__PAGE_OFFSET is just as negative as -__PAGE_OFFSET as far as gas is concerned. It gives me the same warning.

Quoted 3 lines

Quoted 1 line

#define MAXMEM (~__PAGE_OFFSET + 1 - __VMALLOC_RESERVE)

I tried that first, before I came up with the solution in the patch, because I didn't like the dependency of 0xFFFFFFFF being 32-bit. It was a nice idea, but it didn't work. Apparently, gas interprets ~ as a one's complement negation operator, not a bitwise or. Therefore, ~__PAGE_OFFSET is just as negative as -__PAGE_OFFSET as far as gas is concerned. It gives me the same warning.

That would mean a bug in as. __PAGE_OFFSET is unsigned and ~ is documented (not a surprise) as "bitwise not". The bitwise not of __PAGE_OFFSET (unsigned) is still unsigned. BTW 2.14 does not give warnings with both the original statement and the ~ one. This:

        PG=0xC0000000                                                                                                   
        VM=(128 << 20)                                                                                                  
                                                                                                                        
        mov (~PG + 1 - VM), %eax                                                                                        
        mov (-PG - VM), %eax                                                                                            

generate this:

zzzzzzzz: file format elf32-i386

Disassembly of section .text:

00000000 <.text>:

   0:   a1 00 00 00 38          mov    0x38000000,%eax
   5:   a1 00 00 00 38          mov    0x38000000,%eax

w/out any warnings. And the result is obviously 0x38000000 and not 0x37ffffff.

Quoted 30 lines · Davide Libenzi

Quoted 4 lines

Quoted 1 line

#define MAXMEM (~__PAGE_OFFSET + 1 - __VMALLOC_RESERVE)

I tried that first, before I came up with the solution in the patch, because I didn't like the dependency of 0xFFFFFFFF being 32-bit. It was a nice idea, but it didn't work. Apparently, gas interprets ~ as a one's complement negation operator, not a bitwise or. Therefore, ~__PAGE_OFFSET is just as negative as -__PAGE_OFFSET as far as gas is concerned. It gives me the same warning.

That would mean a bug in as. __PAGE_OFFSET is unsigned and ~ is documented (not a surprise) as "bitwise not". The bitwise not of __PAGE_OFFSET (unsigned) is still unsigned. BTW 2.14 does not give warnings with both the original statement and the ~ one. This:

PG=0xC0000000

        VM=(128 << 

20)

        mov (~PG + 1 - VM), 
%eax                                                                                        
        mov (-PG - VM), 

%eax

generate this:

zzzzzzzz: file format elf32-i386

Disassembly of section .text:

00000000 <.text>:

   0:   a1 00 00 00 38          mov    0x38000000,%eax
   5:   a1 00 00 00 38          mov    0x38000000,%eax

Quoted 1 line

w/out any warnings. And the result is obviously 0x38000000 and not 0x37ffffff.

I get the same behaviour. The 0x37ffffff is from the place where MAXMEM is used (the ramdisk_max variable in setup.S); it subtracts one from the value. It turns out that the error only occurs when the value is used in a data definition. Experimentally found first value for which it gives the error is:

ramdisk_max: .long ~(0x80000000)

Interestingly, it doesn't occur for 0x7fffffff. I've taken a look at gas to see where it goes wrong, but my newly built version doesn't exhibit this behaviour -- it compiles the above statement without warnings. It might have to do with the differences between the build environment that the Debian binutils package is built in and my own machine -- I'll do some more investigating.

Now it seems to behave correctly: for '~' it always warns, for '-' it only warns if the negative value is below -0x80000000. I'll submit a patch to this effect (including the format extensions) to the binutils people.

Quoted 4 lines · Bart Samwel

Now it seems to behave correctly: for '~' it always warns, for '-' it only warns if the negative value is below -0x80000000. I'll submit a patch to this effect (including the format extensions) to the binutils people.

binutils 2.14 works fine, so I believe they already fixed it.

Quoted 9 lines · Davide Libenzi

Quoted 4 lines · Bart Samwel

Now it seems to behave correctly: for '~' it always warns, for '-' it only warns if the negative value is below -0x80000000. I'll submit a patch to this effect (including the format extensions) to the binutils people.

binutils 2.14 works fine, so I believe they already fixed it.

I would beg to differ:

--
nosferatu linux # make
make[1]: `arch/i386/kernel/asm-offsets.s' is up to date.

  CHK     include/asm-i386/asm_offsets.h
  CHK     include/linux/compile.h
  AS      arch/i386/boot/setup.o

arch/i386/boot/setup.S: Assembler messages:
arch/i386/boot/setup.S:165: Warning: value 0x37ffffff truncated to 0x37ffffff
LD arch/i386/boot/setup
BUILD arch/i386/boot/bzImage
Root device is (8, 3)
Boot sector 512 bytes.
Setup is 4799 bytes.
System is 1366 kB
Kernel: arch/i386/boot/bzImage is ready

Building modules, stage 2.
MODPOST
nosferatu linux # ld --version
GNU ld version 2.14.90.0.7 20031029
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. nosferatu linux #

Quoted 28 lines · Martin Schlemmer

Quoted 9 lines · Davide Libenzi

Quoted 4 lines · Bart Samwel

Now it seems to behave correctly: for '~' it always warns, for '-' it only warns if the negative value is below -0x80000000. I'll submit a patch to this effect (including the format extensions) to the binutils people.

binutils 2.14 works fine, so I believe they already fixed it.

I would beg to differ:

--
nosferatu linux # make
make[1]: `arch/i386/kernel/asm-offsets.s' is up to date.

  CHK     include/asm-i386/asm_offsets.h
  CHK     include/linux/compile.h
  AS      arch/i386/boot/setup.o

arch/i386/boot/setup.S: Assembler messages:
arch/i386/boot/setup.S:165: Warning: value 0x37ffffff truncated to 0x37ffffff
LD arch/i386/boot/setup
BUILD arch/i386/boot/bzImage
Root device is (8, 3)
Boot sector 512 bytes.
Setup is 4799 bytes.
System is 1366 kB
Kernel: arch/i386/boot/bzImage is ready

Quoted 8 lines

Building modules, stage 2.
MODPOST
nosferatu linux # ld --version
GNU ld version 2.14.90.0.7 20031029
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. nosferatu linux #

Ouch ! I have:

GNU assembler 2.14 20030612

and it works fine. Can you try:

$ as << EOF

	PG=0xC0000000
	VM=(128 << 20)

	.long (-PG -VM)
	.long (~PG + 1 - VM)

EOF

$ objdump -D a.out

VM=(128 << 20)
.long (-PG -VM)
.long (~PG + 1 - VM)
EOF

azarah@nosferatu tar $ as << EOF

Quoted 5 lines

PG=0xC0000000
VM=(128 << 20)
.long (-PG -VM)
.long (~PG + 1 - VM)
EOF

{standard input}: Assembler messages:
{standard input}:3: Warning: value 0x38000000 truncated to 0x38000000 {standard input}:4: Warning: value 0x38000000 truncated to 0x38000000 azarah@nosferatu tar $ objdump -D a.out

a.out: file format elf32-i386

Disassembly of section .text:

00000000 <.text>:

   0:   00 00                   add    %al,(%eax)
   2:   00 38                   add    %bh,(%eax)
   4:   00 00                   add    %al,(%eax)
   6:   00 38                   add    %bh,(%eax)

azarah@nosferatu tar $

Quoted 13 lines · Martin Schlemmer

azarah@nosferatu tar $ as << EOF

Quoted 5 lines

PG=0xC0000000
VM=(128 << 20)
.long (-PG -VM)
.long (~PG + 1 - VM)
EOF

{standard input}: Assembler messages:
{standard input}:3: Warning: value 0x38000000 truncated to 0x38000000 {standard input}:4: Warning: value 0x38000000 truncated to 0x38000000 azarah@nosferatu tar $ objdump -D a.out

a.out: file format elf32-i386

Quoted 8 lines

Disassembly of section .text:

00000000 <.text>:

   0:   00 00                   add    %al,(%eax)
   2:   00 38                   add    %bh,(%eax)
   4:   00 00                   add    %al,(%eax)
   6:   00 38                   add    %bh,(%eax)

azarah@nosferatu tar $

This is weird. I also verified the above with:

GNU assembler 2.13.90.0.18 20030206

and it works fine too.

Quoted 24 lines · Davide Libenzi

Quoted 21 lines · Martin Schlemmer

azarah@nosferatu tar $ as << EOF

Quoted 5 lines

PG=0xC0000000
VM=(128 << 20)
.long (-PG -VM)
.long (~PG + 1 - VM)
EOF

{standard input}: Assembler messages:
{standard input}:3: Warning: value 0x38000000 truncated to 0x38000000 {standard input}:4: Warning: value 0x38000000 truncated to 0x38000000 azarah@nosferatu tar $ objdump -D a.out

a.out: file format elf32-i386

Disassembly of section .text:

00000000 <.text>:

   0:   00 00                   add    %al,(%eax)
   2:   00 38                   add    %bh,(%eax)
   4:   00 00                   add    %al,(%eax)
   6:   00 38                   add    %bh,(%eax)

azarah@nosferatu tar $

Quoted 6 lines

This is weird. I also verified the above with:

GNU assembler 2.13.90.0.18 20030206

and it works fine too.

What distro? Might be an in-house patch ...

Quoted 32 lines · Martin Schlemmer

Quoted 30 lines · Davide Libenzi

Quoted 13 lines · Martin Schlemmer

azarah@nosferatu tar $ as << EOF

Quoted 5 lines

PG=0xC0000000
VM=(128 << 20)
.long (-PG -VM)
.long (~PG + 1 - VM)
EOF

{standard input}: Assembler messages:
{standard input}:3: Warning: value 0x38000000 truncated to 0x38000000 {standard input}:4: Warning: value 0x38000000 truncated to 0x38000000 azarah@nosferatu tar $ objdump -D a.out

a.out: file format elf32-i386

Quoted 8 lines

Disassembly of section .text:

00000000 <.text>:

   0:   00 00                   add    %al,(%eax)
   2:   00 38                   add    %bh,(%eax)
   4:   00 00                   add    %al,(%eax)
   6:   00 38                   add    %bh,(%eax)

azarah@nosferatu tar $

This is weird. I also verified the above with:

GNU assembler 2.13.90.0.18 20030206

and it works fine too.

Quoted 1 line

What distro? Might be an in-house patch ...

The 2.13.90.0.18 is std RH9, while 2.14 is self built. Tested also with FC1:

GNU assembler 2.14.90.0.6 20030820

that is fine too.

Hmm. Ok, ours is compiled with --enable-64-bit-bfd ... might do this? Bit late now, but I'll try to test tomorrow ...

Quoted 1 line

Now it seems to behave correctly: for '~' it always warns, for '-' it only warns if the negative value is below -0x80000000. I'll submit a patch to this effect (including the format extensions) to the binutils people.

binutils 2.14 works fine, so I believe they already fixed it.

Quoted 6 lines · Davide Libenzi

Quoted 4 lines

Now it seems to behave correctly: for '~' it always warns, for '-' it only warns if the negative value is below -0x80000000. I'll submit a patch to this effect (including the format extensions) to the binutils people.

binutils 2.14 works fine, so I believe they already fixed it.

Against your code, yes. I'm using binutils 2.14 as well. Check it when declaring a .long, like the kernel code does. Then it warns.

PG=0xC0000000
VM=(128 << 20)
.long (-PG - VM) - 1
.long (~PG + 1 - VM) - 1
EOF

Also, most important, the make bzImage does not give any warnings.

Quoted 8 lines · Tim Cambrant

Quoted 6 lines · Mario Vanoni

Compiling the kernel under 2.6.1-mm2, gcc-3.3.2 (same messages as under 2.6.1-rc1-mm1, re-tested),

arch/i386/boot/setup.S: Assembler messages:
arch/i386/boot/setup.S:165: Warning: value 0x37ffffff truncated to 0x37ffffff

Quoted 7 lines

This is apparently a known problem and has existed for a long time, but no-one has fixed it for some reason. I asked the exacly same question a few months ago, and someone told me that this issue has been around forever, but is noticed under 2.6, since it is less verbose during the compilation. I'll pass the message that was told to me: If you've got a fix, it would surely be included in the kernel.

The problem is in the MAXMEM macro. This macro takes the inverse of a positive number, subtracts another number, and the negative result overflows the negative range of a 32-bit integer. The assembler truncates it, but apparently it can't print overly negative numbers correctly, that's why it looks so strange.

My proposed fix is attached: change the macro to subtract the numbers from 0xFFFFFFFF, and then add 1 at the end. That yields the same result, but without going through a negative intermediate value that needs to be truncated.

-- Bart

Quoted 37 lines · Bart Samwel

Quoted 9 lines · Tim Cambrant

Quoted 6 lines · Mario Vanoni

Compiling the kernel under 2.6.1-mm2, gcc-3.3.2 (same messages as under 2.6.1-rc1-mm1, re-tested),

arch/i386/boot/setup.S: Assembler messages:
arch/i386/boot/setup.S:165: Warning: value 0x37ffffff truncated to 0x37ffffff

Quoted 7 lines

This is apparently a known problem and has existed for a long time, but no-one has fixed it for some reason. I asked the exacly same question a few months ago, and someone told me that this issue has been around forever, but is noticed under 2.6, since it is less verbose during the compilation. I'll pass the message that was told to me: If you've got a fix, it would surely be included in the kernel.

The problem is in the MAXMEM macro. This macro takes the inverse of a positive number, subtracts another number, and the negative result overflows the negative range of a 32-bit integer. The assembler truncates it, but apparently it can't print overly negative numbers correctly, that's why it looks so strange.

My proposed fix is attached: change the macro to subtract the numbers from 0xFFFFFFFF, and then add 1 at the end. That yields the same result, but without going through a negative intermediate value that needs to be truncated.

-- Bart

page.h line 129

Quoted 8 lines

page.h renamed from page.h.orig +1 -1

@@ -123,7 +123,7 @@
 
 #define PAGE_OFFSET		((unsigned long)__PAGE_OFFSET)
 #define VMALLOC_RESERVE		((unsigned long)__VMALLOC_RESERVE)
-#define MAXMEM			(-__PAGE_OFFSET-__VMALLOC_RESERVE)
+#define MAXMEM			(0xFFFFFFFF-__PAGE_OFFSET-__VMALLOC_RESERVE+1)
 #define __pa(x)			((unsigned long)(x)-PAGE_OFFSET)
 #define __va(x)			((void *)((unsigned long)(x)+PAGE_OFFSET))
 #define pfn_to_kaddr(pfn)      __va((pfn) << PAGE_SHIFT)

This looks like a neat fix, faint praise from someone who doesn't know THAT much about it. However, the question folks like me are going to ask is which of the approximately 24 page.h's in the kernel tree (for 2.6.1-mm1 anyway) does this actually apply to?

Ahh, grep to the rescue, its include/asm/page.h

However, on checking my copy, I find a different fix there:

#define MAXMEM ((unsigned long)(-PAGE_OFFSET-VMALLOC_RESERVE))

Which I note doesn't use the PAGE_OFFSET defined a few lines up Which is correct?

Gene Heskett wrote:

Quoted 1 line

Which is correct?

This is a C macro. Apparently in your arch it isn't used in any assembler code. The reason that i386 doesn't cast to unsigned long is that casts aren't an assembler construct, and this macro is used in arch/i386/boot/setup.S. Also, PAGE_OFFSET includes an (unsigned long) cast as well, __PAGE_OFFSET doesn't, and that explains why i386 uses __PAGE_OFFSET.

-- Bart

Quoted 7 lines · Mario Vanoni

Compiling the kernel under 2.6.1-mm2, gcc-3.3.2 (same messages as under 2.6.1-rc1-mm1, re-tested),

arch/i386/boot/setup.S: Assembler messages:
arch/i386/boot/setup.S:165: Warning: value 0x37ffffff truncated to 0x37ffffff

If you've got a fix, it would surely be included in the kernel.

- I didn't try to boot the patched kernel yet.