2.6.1-mm2: compiler warning

2.6.1-mm2: compiler warning

[Mario Vanoni]

P4-3066HT with 1GB mem

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

but compiles.

Rebooting with this kernel (2 times tested)
then trying to recompile the kernel,
no crashes as with 2.6.1-rc2-mm1.
Every time using the last compiled bzImage.

Mario, _not_ in lkml.

Re: 2.6.1-mm2: compiler warning

[Tim Cambrant]

On Sat, Jan 10, 2004 at 04:40:30PM +0100, Mario Vanoni wrote:
> 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.

                Tim Cambrant

[PATCH][TRIVIAL] Remove bogus "value 0x37ffffff truncated to 0x37ffffff" warning.

[Bart Samwel]

Tim Cambrant wrote:
> On Sat, Jan 10, 2004 at 04:40:30PM +0100, Mario Vanoni wrote:
> 
>>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.

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.orig	2004-01-10 18:15:17.000000000 +0100
+++ page.h	2004-01-10 18:15:47.000000000 +0100
@@ -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)

Re: [PATCH][TRIVIAL] Remove bogus "value 0x37ffffff truncated to 0x37ffffff" warning.

[Davide Libenzi]

On Sat, 10 Jan 2004, Bart Samwel wrote:

> Tim Cambrant wrote:
> > On Sat, Jan 10, 2004 at 04:40:30PM +0100, Mario Vanoni wrote:
> > 
> >>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.
> 
> 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.orig	2004-01-10 18:15:17.000000000 +0100
> +++ page.h	2004-01-10 18:15:47.000000000 +0100
> @@ -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)



- Davide

Re: [PATCH][TRIVIAL] Remove bogus "value 0x37ffffff truncated to 0x37ffffff" warning.

[Bart Samwel]

Davide Libenzi wrote:
> On Sat, 10 Jan 2004, Bart Samwel wrote:
> 
> 
>>Tim Cambrant wrote:
>>
>>>On Sat, Jan 10, 2004 at 04:40:30PM +0100, Mario Vanoni wrote:
>>>
>>>
>>>>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.
>>
>>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.orig	2004-01-10 18:15:17.000000000 +0100
>>+++ page.h	2004-01-10 18:15:47.000000000 +0100
>>@@ -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)

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.

-- Bart

Re: [PATCH][TRIVIAL] Remove bogus "value 0x37ffffff truncated to 0x37ffffff" warning.

[Davide Libenzi]

On Sat, 10 Jan 2004, Bart Samwel wrote:

> >>--- page.h.orig	2004-01-10 18:15:17.000000000 +0100
> >>+++ page.h	2004-01-10 18:15:47.000000000 +0100
> >>@@ -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)
> 
> 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.



- Davide

Re: [PATCH][TRIVIAL] Remove bogus "value 0x37ffffff truncated to 0x37ffffff" warning.

[Bart Samwel]

Davide Libenzi wrote:
>>>#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.

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.

-- Bart

Re: [PATCH][TRIVIAL] Remove bogus "value 0x37ffffff truncated to 0x37ffffff" warning.

[Bart Samwel]

Bart Samwel wrote:
> Davide Libenzi wrote:
> 
>>>> #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.
> 
> 
> 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.

OK, I've done a bit of investigation. It turns out that as generates 
this warning when the following condition is met:

       if ((get & mask) != 0
	  && ((get & mask) != mask
	      || (get & hibit) == 0))

I've modified the warning to give me some more info about the values 
involved:

test.S: Assembler messages:
test.S:3: Warning: value 0xffffffff7fffffff truncated to 0x7fffffff, 
mask = ffffffff00000000, unmask = ffffffff, (get & mask) = 
ffffffff00000000), sizeof(get) = 8, sizeof(mask) = 8

This could be correct if as interpreted ~ as a 64-bit binary not, not a 
32-bit one. Not quite unlogical (it doesn't know the type of the input 
value -- it's a literal), except that it doesn't print the full value 
when it truncates it. I find it strange though that the warning isn't 
given for values under 0x80000000! This turns out to have to do with the 
"hibit", which turns out to be 0x80000000. Basically, their logic is 
that if (get & mask) == mask (all upper bits are 1) and (get & hibit) != 
0 as well, then the number is fits within a 32 bits *signed* integer. 
However, they don't look at the unsignedness of the value. So, I've 
changed this to:


       if ((get & mask) != 0
	  && (exp->X_unsigned
               || (get & mask) != mask
	      || (get & hibit) == 0))

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.

What's the effect of this for the linux warning? We don't want to use ~ 
for this, because it's not a 32-bit binary not. So, we need to use 
either my solution or the one supplied by Hans.

-- Bart

Re: [PATCH][TRIVIAL] Remove bogus "value 0x37ffffff truncated to 0x37ffffff" warning.

[Davide Libenzi]

On Sun, 11 Jan 2004, Bart Samwel wrote:

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



- Davide

Re: [PATCH][TRIVIAL] Remove bogus "value 0x37ffffff truncated to 0x37ffffff" warning.

[Martin Schlemmer]

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

On Sun, 2004-01-11 at 18:53, Davide Libenzi wrote:
> On Sun, 11 Jan 2004, Bart Samwel wrote:
> 
> > 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 #
--


-- 
Martin Schlemmer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH][TRIVIAL] Remove bogus "value 0x37ffffff truncated to 0x37ffffff" warning.

[Davide Libenzi]

On Sun, 11 Jan 2004, Martin Schlemmer wrote:

> On Sun, 2004-01-11 at 18:53, Davide Libenzi wrote:
> > On Sun, 11 Jan 2004, Bart Samwel wrote:
> > 
> > > 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 #

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




- Davide

Re: [PATCH][TRIVIAL] Remove bogus "value 0x37ffffff truncated to 0x37ffffff" warning.

[Martin Schlemmer]

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

On Sun, 2004-01-11 at 19:53, Davide Libenzi wrote:
> On Sun, 11 Jan 2004, Martin Schlemmer wrote:
> 
> > On Sun, 2004-01-11 at 18:53, Davide Libenzi wrote:
> > > On Sun, 11 Jan 2004, Bart Samwel wrote:
> > > 
> > > > 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 #
> 
> 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
> 
> 

--
azarah@nosferatu tar $ as << EOF > 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 $
--



-- 
Martin Schlemmer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH][TRIVIAL] Remove bogus "value 0x37ffffff truncated to 0x37ffffff" warning.

[Davide Libenzi]

On Sun, 11 Jan 2004, Martin Schlemmer wrote:

> azarah@nosferatu tar $ as << EOF
> > 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 $

This is weird. I also verified the above with:

GNU assembler 2.13.90.0.18 20030206

and it works fine too.




- Davide

Re: [PATCH][TRIVIAL] Remove bogus "value 0x37ffffff truncated to 0x37ffffff" warning.

[Martin Schlemmer]

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

On Sun, 2004-01-11 at 20:42, Davide Libenzi wrote:
> On Sun, 11 Jan 2004, Martin Schlemmer wrote:
> 
> > azarah@nosferatu tar $ as << EOF
> > > 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 $
> 
> 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 ...


-- 
Martin Schlemmer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH][TRIVIAL] Remove bogus "value 0x37ffffff truncated to 0x37ffffff" warning.

[Davide Libenzi]

On Sun, 11 Jan 2004, Martin Schlemmer wrote:

> On Sun, 2004-01-11 at 20:42, Davide Libenzi wrote:
> > On Sun, 11 Jan 2004, Martin Schlemmer wrote:
> > 
> > > azarah@nosferatu tar $ as << EOF
> > > > 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 $
> > 
> > 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 ...

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.



- Davide

Re: [PATCH][TRIVIAL] Remove bogus "value 0x37ffffff truncated to 0x37ffffff" warning.

[Martin Schlemmer]

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

On Sun, 2004-01-11 at 22:47, Davide Libenzi wrote:
> On Sun, 11 Jan 2004, Martin Schlemmer wrote:
> 
> > On Sun, 2004-01-11 at 20:42, Davide Libenzi wrote:
> > > On Sun, 11 Jan 2004, Martin Schlemmer wrote:
> > > 
> > > > azarah@nosferatu tar $ as << EOF
> > > > > 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 $
> > > 
> > > 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 ...
> 
> 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 ...


-- 
Martin Schlemmer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH][TRIVIAL] Remove bogus "value 0x37ffffff truncated to 0x37ffffff" warning.

[Bart Samwel]

Martin Schlemmer wrote:

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

That might definitely do it. offsetT (the type of values in gas) is 
defined as:

typedef bfd_signed_vma offsetT;

That DEFINITELY looks like the bit-size of bfd has an influence. In my 
program, offsetT is 64-bits -- looks like the default for Debian is 
--enable-64-bit-bfd. This explains why I didn't get a warning for my 
custom-built version, but I *did* get it for the version built by 
dpkg-buildpackage. Looks like we've got the final cause of the suddenly 
appearing warning.

-- Bart

Re: [PATCH][TRIVIAL] Remove bogus "value 0x37ffffff truncated to 0x37ffffff" warning.

[Bart Samwel]

Davide Libenzi wrote:
>>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.

-- Bart

Re: [PATCH][TRIVIAL] Remove bogus "value 0x37ffffff truncated to 0x37ffffff" warning.

[Davide Libenzi]

On Mon, 12 Jan 2004, Bart Samwel wrote:

> Davide Libenzi wrote:
> >>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.

Nope. It does not. Tested on three versions of binutils:

[davide@bigblue davide]$ as << EOF
> PG=0xC0000000
> VM=(128 << 20)
> .long (-PG - VM) - 1
> .long (~PG + 1 - VM) - 1
> EOF
[davide@bigblue davide]$ objdump -D a.out 

a.out:     file format elf32-i386

Disassembly of section .text:

00000000 <.text>:
   0:   ff                      (bad)  
   1:   ff                      (bad)  
   2:   ff 37                   pushl  (%edi)
   4:   ff                      (bad)  
   5:   ff                      (bad)  
   6:   ff 37                   pushl  (%edi)
Disassembly of section .data:


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



- Davide

Re: [PATCH][TRIVIAL] Remove bogus "value 0x37ffffff truncated to 0x37ffffff" warning.

[Bart Samwel]

Davide Libenzi wrote:
> Also, most important, the `make bzImage` does not give any warnings.

Hmmm. Did you get the original warning that we were talking about, 
before any changes were made? It still gives *me* the warnings, 
regardless of how it's written. What arch/compiler are you on? If you're 
on an arch/compiler that makes gas do 32-bit arithmetic, you're not 
going to get any warning -- it's going to be fine, because of gas's 
warning logic. I use an i386/gcc 3.3 system (debian unstable). Do you 
get no warnings as well on that configuration?

-- Bart

Re: [PATCH][TRIVIAL] Remove bogus "value 0x37ffffff truncated to 0x37ffffff" warning.

[Gene Heskett]

On Saturday 10 January 2004 12:28, Bart Samwel wrote:
>Tim Cambrant wrote:
>> On Sat, Jan 10, 2004 at 04:40:30PM +0100, Mario Vanoni wrote:
>>>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.
>
>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.orig	2004-01-10 18:15:17.000000000 +0100
>+++ page.h	2004-01-10 18:15:47.000000000 +0100
>@@ -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?

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty: soap,
ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

Re: [PATCH][TRIVIAL] Remove bogus "value 0x37ffffff truncated to 0x37ffffff" warning.

[Bart Samwel]

Gene Heskett wrote:
> On Saturday 10 January 2004 12:28, Bart Samwel wrote:
> 
>>Tim Cambrant wrote:
>>
>>>On Sat, Jan 10, 2004 at 04:40:30PM +0100, Mario Vanoni wrote:
>>>
>>>>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.
>>
>>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.orig	2004-01-10 18:15:17.000000000 +0100
>>+++ page.h	2004-01-10 18:15:47.000000000 +0100
>>@@ -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?

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

Re: [PATCH][TRIVIAL] Remove bogus "value 0x37ffffff truncated to 0x37ffffff" warning.

[Gene Heskett]

On Saturday 10 January 2004 15:14, Bart Samwel wrote:
>Gene Heskett wrote:
[...]
>> 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

Thanks, that clears it up to me.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty: soap,
ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

Re: 2.6.1-mm2: compiler warning

[Hans Ulrich Niedermann]

Tim Cambrant <tim@cambrant.com> writes:

> On Sat, Jan 10, 2004 at 04:40:30PM +0100, Mario Vanoni wrote:
>> 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.

Hmm... let's see...

The assembler calculates in arch/i386/boot/setup.S (with the
definition of MAXMEM from include/asm-i386/page.h):

        - 0xC0000000 - 0x08000000 - 1

This obviously is a negative number which is what the assembler
warns us about.

As there are no negative memory addresses anyway, the number we really
want is the positive number

        (1 << 32) - 0xC0000000 - 0x08000000 - 1

which is the same in modulo (1 << 32) arithmetic, of course.

Original arch/i386/boot/setup.o (subtract from 0):

0000002c <ramdisk_max>:
      2c:	ff                   	(bad)  
      2d:	ff                   	(bad)  
      2e:	ff 37                	pushl  (%edi)

Patched arch/i386/boot/setup.o (subtract from (1<<32)):

0000002c <ramdisk_max>:
      2c:	ff                   	(bad)  
      2d:	ff                   	(bad)  
      2e:	ff 37                	pushl  (%edi)

This looks OK to me so far.

However, a few issues remain:

- There probably are some nasty side effects in other places
  which I haven't thought about.

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

- As I don't know whether the C compiler might get confused about
  that, I re-used the #ifdef in include/asm-i386/page.h.
  Subtracting UL constants from (0UL) shouldn't make a difference,
  even if subtracting from 0x100000000UL might.

- __MAXMEM_ADDRSPACE_MAX should probably be defined using a
  constant from somewhere else. (Where from?)

Regards,

Uli

--- linux-2.6.1/include/asm-i386/page.h.orig	Sat Jan 10 18:01:31 2004
+++ linux-2.6.1/include/asm-i386/page.h	Sat Jan 10 18:03:48 2004
@@ -116,14 +116,16 @@
 
 #ifdef __ASSEMBLY__
 #define __PAGE_OFFSET		(0xC0000000)
+#define __MAXMEM_ADDRSPACE_MAX	(1 << 32)
 #else
 #define __PAGE_OFFSET		(0xC0000000UL)
+#define __MAXMEM_ADDRSPACE_MAX	(0UL)
 #endif
 
 
 #define PAGE_OFFSET		((unsigned long)__PAGE_OFFSET)
 #define VMALLOC_RESERVE		((unsigned long)__VMALLOC_RESERVE)
-#define MAXMEM			(-__PAGE_OFFSET-__VMALLOC_RESERVE)
+#define MAXMEM			(__MAXMEM_ADDRSPACE_MAX-__PAGE_OFFSET-__VMALLOC_RESERVE)
 #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)

Re: 2.6.1-mm2: compiler warning

[Petri Koistinen]

Hi!

On Sat, 10 Jan 2004, Hans Ulrich Niedermann wrote:

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

It boots and seems to be working, don't have expertise to say anything
else. Perhaps you should queue it via Rusty to expert review, see:
http://www.kernel.org/pub/linux/kernel/people/rusty/trivial/

Petri