All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.