Messages in this thread | | | Date | Sun, 11 Jan 2004 01:25:04 +0100 | From | Bart Samwel <> | Subject | Re: [PATCH][TRIVIAL] Remove bogus "value 0x37ffffff truncated to 0x37ffffff" warning. |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |