From: Bart Samwel <bart@samwel.tk>
To: gene.heskett@verizon.net
Cc: Tim Cambrant <tim@cambrant.com>,
Mario Vanoni <vanonim@bluewin.ch>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH][TRIVIAL] Remove bogus "value 0x37ffffff truncated to 0x37ffffff" warning.
Date: Sat, 10 Jan 2004 21:14:33 +0100 [thread overview]
Message-ID: <40005D29.5090803@samwel.tk> (raw)
In-Reply-To: <200401101342.40728.gene.heskett@verizon.net>
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
next prev parent reply other threads:[~2004-01-10 20:15 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-10 15:40 2.6.1-mm2: compiler warning Mario Vanoni
2004-01-10 15:56 ` Tim Cambrant
2004-01-10 17:28 ` [PATCH][TRIVIAL] Remove bogus "value 0x37ffffff truncated to 0x37ffffff" warning Bart Samwel
2004-01-10 17:39 ` Davide Libenzi
2004-01-10 20:20 ` Bart Samwel
2004-01-10 21:04 ` Davide Libenzi
2004-01-11 0:25 ` Bart Samwel
2004-01-11 13:58 ` Bart Samwel
2004-01-11 16:53 ` Davide Libenzi
2004-01-11 17:44 ` Martin Schlemmer
2004-01-11 17:53 ` Davide Libenzi
2004-01-11 18:38 ` Martin Schlemmer
2004-01-11 18:42 ` Davide Libenzi
2004-01-11 18:47 ` Martin Schlemmer
2004-01-11 20:47 ` Davide Libenzi
2004-01-11 21:29 ` Martin Schlemmer
2004-01-12 1:15 ` Bart Samwel
2004-01-12 0:48 ` Bart Samwel
2004-01-12 0:52 ` Davide Libenzi
2004-01-12 1:10 ` Bart Samwel
2004-01-10 18:42 ` Gene Heskett
2004-01-10 20:14 ` Bart Samwel [this message]
2004-01-10 20:50 ` Gene Heskett
2004-01-10 17:31 ` 2.6.1-mm2: compiler warning Hans Ulrich Niedermann
2004-01-10 23:40 ` Petri Koistinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40005D29.5090803@samwel.tk \
--to=bart@samwel.tk \
--cc=akpm@osdl.org \
--cc=gene.heskett@verizon.net \
--cc=linux-kernel@vger.kernel.org \
--cc=tim@cambrant.com \
--cc=vanonim@bluewin.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox