public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Hans Ulrich Niedermann <linux-kernel@n-dimensional.de>
To: Tim Cambrant <tim@cambrant.com>
Cc: Mario Vanoni <vanonim@bluewin.ch>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.1-mm2: compiler warning
Date: Sat, 10 Jan 2004 18:31:42 +0100	[thread overview]
Message-ID: <86r7y7pv5t.fsf@n-dimensional.de> (raw)
In-Reply-To: <20040110155626.GA20684@cambrant.com> (Tim Cambrant's message of "Sat, 10 Jan 2004 16:56:26 +0100")

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)

  parent reply	other threads:[~2004-01-10 17:35 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
2004-01-10 20:50         ` Gene Heskett
2004-01-10 17:31   ` Hans Ulrich Niedermann [this message]
2004-01-10 23:40     ` 2.6.1-mm2: compiler warning 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=86r7y7pv5t.fsf@n-dimensional.de \
    --to=linux-kernel@n-dimensional.de \
    --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