Re: RH7.3 can't compile 2.6.0-test8

Re: RH7.3 can't compile 2.6.0-test8

[rwhron]

> The Readme for 2.6.0-test6 still said that gcc 2.95 is required

test8 Changes still says gcc-2.95.3.  I saw the same compile error
on RedHat 7.2.  I ended up using gcc-3.3.1.  Later I saw this patch:

http://marc.theaimsgroup.com/?l=linux-kernel&m=106651554401143&w=2

It's supposed to fix test8 compile with gcc-2.96 for RedHat 7.x.

-- 
Randy Hron
http://home.earthlink.net/~rwhron/kernel/bigbox.html

Re: RH7.3 can't compile 2.6.0-test8

[Marco Roeland]

Op dinsdag 21 oktober 2003 om 09:19 uur schreef rwhron@earthlink.net het volgende:

> > The Readme for 2.6.0-test6 still said that gcc 2.95 is required
> 
> test8 Changes still says gcc-2.95.3.  I saw the same compile error
> on RedHat 7.2.  I ended up using gcc-3.3.1.  Later I saw this patch:
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=106651554401143&w=2
> 
> It's supposed to fix test8 compile with gcc-2.96 for RedHat 7.x.

It seems an odd fix though, the variable tty_nr is at most set once
inside the function, and is inaccessible to other functions so why it
should be volatile seems unclear to me. It might solve the compilation
(now that I look again the original error messages mention gcc internal
representation, so the suggestion of binutils at fault seems unwarranted)
but that seems by accident, not by design?

Perhaps if the huge sprintf with 40+ arguments (fs/proc/array.c, line 346)
amongst which several trinary operators, were to be split up into several
parts, might that not solve the problem more elegantly?
-- 
Marco Roeland

Re: [PATCH] RH7.3 can't compile 2.6.0-test8 (fs/proc/array.c)

[Marco Roeland]

On Tuesday October 21st 2003 at 15:52 uur Marco Roeland wrote:

> > http://marc.theaimsgroup.com/?l=linux-kernel&m=106651554401143&w=2
> > 
> > It's supposed to fix test8 compile with gcc-2.96 for RedHat 7.x.
> 
> Perhaps if the huge sprintf with 40+ arguments (fs/proc/array.c, line 346)
> amongst which several trinary operators, were to be split up into several
> parts, might that not solve the problem more elegantly?

Does this compile (and work) for any of you friendly RedHat 7.[23] users? 
In 2.6.0-test8 yet another argument was added to the monstrous sprintf.
Perhaps this was just the droplet to overflow gcc-2.96's buckets? Here we
split it into 3 distinct parts.

--- linux-2.6.0-test8/fs/proc/array.c.orig	2003-10-21 16:18:40.000000000 +0200
+++ linux-2.6.0-test8/fs/proc/array.c	2003-10-21 16:24:42.000000000 +0200
@@ -343,9 +343,7 @@
 	read_lock(&tasklist_lock);
 	ppid = task->pid ? task->real_parent->pid : 0;
 	read_unlock(&tasklist_lock);
-	res = sprintf(buffer,"%d (%s) %c %d %d %d %d %d %lu %lu \
-%lu %lu %lu %lu %lu %ld %ld %ld %ld %d %ld %llu %lu %ld %lu %lu %lu %lu %lu \
-%lu %lu %lu %lu %lu %lu %lu %lu %d %d %lu %lu\n",
+	res = sprintf(buffer,"%d (%s) %c %d %d %d %d %d %lu %lu ",
 		task->pid,
 		task->comm,
 		state,
@@ -355,7 +353,8 @@
 		tty_nr,
 		tty_pgrp,
 		task->flags,
-		task->min_flt,
+		task->min_flt);
+	res += sprintf(buffer + res,"%lu %lu %lu %lu %lu %ld %ld %ld %ld %d %ld %llu %lu %ld %lu %lu %lu %lu %lu ",
 		task->cmin_flt,
 		task->maj_flt,
 		task->cmaj_flt,
@@ -375,7 +374,8 @@
 		mm ? mm->start_code : 0,
 		mm ? mm->end_code : 0,
 		mm ? mm->start_stack : 0,
-		esp,
+		esp);
+	res += sprintf(buffer + res,"%lu %lu %lu %lu %lu %lu %lu %lu %d %d %lu %lu\n",
 		eip,
 		/* The signal information here is obsolete.
 		 * It must be decimal for Linux 2.0 compatibility.

Re: [PATCH] RH7.3 can't compile 2.6.0-test8 (fs/proc/array.c)

[Paul Larson]

On Tue, 2003-10-21 at 09:37, Marco Roeland wrote:
> Does this compile (and work) for any of you friendly RedHat 7.[23] users? 
> In 2.6.0-test8 yet another argument was added to the monstrous sprintf.
> Perhaps this was just the droplet to overflow gcc-2.96's buckets? Here we
> split it into 3 distinct parts.
Works on my machine.

-Paul Larson

Re: [PATCH] RH7.3 can't compile 2.6.0-test8 (fs/proc/array.c)

[bill davidsen]

In article <20031021143741.GB22633@localhost>,
Marco Roeland  <marco.roeland@xs4all.nl> wrote:
| On Tuesday October 21st 2003 at 15:52 uur Marco Roeland wrote:
| 
| > > http://marc.theaimsgroup.com/?l=linux-kernel&m=106651554401143&w=2
| > > 
| > > It's supposed to fix test8 compile with gcc-2.96 for RedHat 7.x.
| > 
| > Perhaps if the huge sprintf with 40+ arguments (fs/proc/array.c, line 346)
| > amongst which several trinary operators, were to be split up into several
| > parts, might that not solve the problem more elegantly?
| 
| Does this compile (and work) for any of you friendly RedHat 7.[23] users? 
| In 2.6.0-test8 yet another argument was added to the monstrous sprintf.
| Perhaps this was just the droplet to overflow gcc-2.96's buckets? Here we
| split it into 3 distinct parts.

Thank you!
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [PATCH] RH7.3 can't compile 2.6.0-test8 (fs/proc/array.c)

[Norman Diamond]

Marco Roeland asked:

> Does this compile (and work) for any of you friendly RedHat 7.[23] users?
> In 2.6.0-test8 yet another argument was added to the monstrous sprintf.
> Perhaps this was just the droplet to overflow gcc-2.96's buckets? Here we
> split it into 3 distinct parts.

It didn't help in RH 7.3.
Again the word エラー in the following excerpt means error.


fs/proc/array.c: In function `proc_pid_stat':
fs/proc/array.c:398: Unrecognizable insn:
(insn/i 1325 1690 1684 (parallel[
            (set (reg:SI 0 eax)
                (asm_operands ("") ("=a") 0[
                        (reg:DI 1 edx)
                    ]
                    [
                        (asm_input:DI ("A"))
                    ]  ("include/linux/times.h") 37))
            (set (reg:SI 1 edx)
                (asm_operands ("") ("=d") 1[
                        (reg:DI 1 edx)
                    ]
                    [
                        (asm_input:DI ("A"))
                    ]  ("include/linux/times.h") 37))
            (clobber (reg:QI 19 dirflag))
            (clobber (reg:QI 18 fpsr))
            (clobber (reg:QI 17 flags))
        ] ) -1 (insn_list 1319 (nil))
    (nil))
fs/proc/array.c:398: confused by earlier errors, bailing out
make[2]: *** [fs/proc/array.o] エラー 1
make[1]: *** [fs/proc] エラー 2
make: *** [fs] エラー 2


Line 37 of include/linux/times.h is the do_div call shown below.


static inline u64 jiffies_64_to_clock_t(u64 x)
{
#if (HZ % USER_HZ)==0
        do_div(x, HZ / USER_HZ);

Re: [PATCH] RH7.3 can't compile 2.6.0-test8 (fs/proc/array.c)

[Marco Roeland]

On Thursday Oktober 23 2003 at 10:16 uur Norman Diamond wrote:

> Marco Roeland wrote (privately but I hope not secretly :-)

I hope you didn't circumvent any digital information rights management
schemes?  ;-) No, my fault. Private communication is very un-open-source!
I wrote without access to sources (only some recent patches available) in
a very noisy office and was afraid my post would be as clear as a long quote
from Ulysses.
 
> > Perhaps working out the jiffies call in a separate variable
> > long long tmp = jiffies_64_to_clock_t(...); and then using
> > that in the sprintf() might work?
> 
> unsigned long long.
> 
> It worked.  I made this change after applying the patch
> previously posted by Mr. Roeland.  I think the present
> workaround might also work without the previous patch,
> and will try it that way if I have time.

Ok! As the compiler seems to be at the edge of overasking its capabilities
(three *different* simplifications which each should normally haven't made
any difference *did* make it compile for different people with gcc 2.96)
it might not be a bad idea to apply both simplifications (the 'volatile'
solution I think is not proper C here).
 
> Again this is with Red Hat's nonstandard gcc 2.96.

Well it is standard to RedHat 7! If a slight simplification makes it
work again whats wrong with that, as long as its proper C?

Ok, so we have something like this:

Simplify a longish expression so that gcc 2.96 doesn't choke on it.

--- linux-2.6.0-test8/fs/proc/array.c.orig	2003-10-21 16:18:40.000000000 +0200
+++ linux-2.6.0-test8/fs/proc/array.c	2003-10-23 09:30:27.000000000 +0200
@@ -302,6 +302,7 @@
 	pid_t ppid;
 	int num_threads = 0;
 	struct mm_struct *mm;
+	unsigned long long starttime;
 
 	state = *get_task_state(task);
 	vsize = eip = esp = 0;
@@ -343,9 +344,7 @@
 	read_lock(&tasklist_lock);
 	ppid = task->pid ? task->real_parent->pid : 0;
 	read_unlock(&tasklist_lock);
-	res = sprintf(buffer,"%d (%s) %c %d %d %d %d %d %lu %lu \
-%lu %lu %lu %lu %lu %ld %ld %ld %ld %d %ld %llu %lu %ld %lu %lu %lu %lu %lu \
-%lu %lu %lu %lu %lu %lu %lu %lu %d %d %lu %lu\n",
+	res = sprintf(buffer,"%d (%s) %c %d %d %d %d %d %lu %lu ",
 		task->pid,
 		task->comm,
 		state,
@@ -355,7 +354,9 @@
 		tty_nr,
 		tty_pgrp,
 		task->flags,
-		task->min_flt,
+		task->min_flt);
+	starttime = jiffies_64_to_clock_t(task->start_time - INITIAL_JIFFIES);
+	res += sprintf(buffer + res,"%lu %lu %lu %lu %lu %ld %ld %ld %ld %d %ld %llu %lu %ld %lu %lu %lu %lu %lu ",
 		task->cmin_flt,
 		task->maj_flt,
 		task->cmaj_flt,
@@ -367,15 +368,15 @@
 		nice,
 		num_threads,
 		jiffies_to_clock_t(task->it_real_value),
-		(unsigned long long)
-		    jiffies_64_to_clock_t(task->start_time - INITIAL_JIFFIES),
+		starttime,
 		vsize,
 		mm ? mm->rss : 0, /* you might want to shift this left 3 */
 		task->rlim[RLIMIT_RSS].rlim_cur,
 		mm ? mm->start_code : 0,
 		mm ? mm->end_code : 0,
 		mm ? mm->start_stack : 0,
-		esp,
+		esp);
+	res += sprintf(buffer + res,"%lu %lu %lu %lu %lu %lu %lu %lu %d %d %lu %lu\n",
 		eip,
 		/* The signal information here is obsolete.
 		 * It must be decimal for Linux 2.0 compatibility.

Re: [PATCH] RH7.3 can't compile 2.6.0-test8 (fs/proc/array.c)

[ndiamond]

Marco Roeland wrote (privately but I hope not secretly :-)

> Perhaps working out the jiffies call in a separate variable
> long long tmp = jiffies_64_to_clock_t(...); and then using
> that in the sprintf() might work?

unsigned long long.

It worked.  I made this change after applying the patch
previously posted by Mr. Roeland.  I think the present
workaround might also work without the previous patch,
and will try it that way if I have time.

Again this is with Red Hat's nonstandard gcc 2.96.
At the moment it looks like Red Hat's gcc is to blame here.