In fs/proc/array.c error in function proc_pid_stat

In fs/proc/array.c error in function proc_pid_stat

[Surya prabhakar]

Hai all , 
    When trying to compile 2.6.0-test11 . I am getting a compile time error as below

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

 I compilng it frame pointers disabled . 

Any suggestion

rgds
Surya.
-- 
______________________________________________
Check out the latest SMS services @ http://www.linuxmail.org 
This allows you to send and receive SMS through your mailbox.


Powered by Outblaze

Re: In fs/proc/array.c error in function proc_pid_stat

[William Lee Irwin III]

On Sat, Dec 13, 2003 at 10:51:01PM +0500, Surya prabhakar wrote:
> Hai all , 
>     When trying to compile 2.6.0-test11 . I am getting a compile time
> error as below

This is a gcc problem fixed in newer gcc versions.


-- wli

Re: In fs/proc/array.c error in function proc_pid_stat

[(-> surya <-)]

Dear Lee,
   Thx for the reply . Anyway I patched array.c with this patch(available in the lists posted by Marco Roeland )  , it was working fine .
 
rgds
surya
_____________________________________________________________________________________

--- 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,
___________________________________________________________________________________________________



----- Original Message -----
From: William Lee Irwin III <wli@holomorphy.com>
Date: 	Sat, 13 Dec 2003 09:57:17 -0800
To: Surya prabhakar <surya_prabhakar@linuxmail.org>
Subject: Re: In fs/proc/array.c error in function proc_pid_stat

> On Sat, Dec 13, 2003 at 10:51:01PM +0500, Surya prabhakar wrote:
> > Hai all , 
> >     When trying to compile 2.6.0-test11 . I am getting a compile time
> > error as below
> 
> This is a gcc problem fixed in newer gcc versions.
> 
> 
> -- wli
> -
> 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/



rgds
surya

-- 
______________________________________________
Check out the latest SMS services @ http://www.linuxmail.org 
This allows you to send and receive SMS through your mailbox.


Powered by Outblaze

Re: In fs/proc/array.c error in function proc_pid_stat

[William Lee Irwin III]

On Sun, Dec 14, 2003 at 12:25:15AM +0500, (-> surya <-)  wrote:
>    Thx for the reply . Anyway I patched array.c with this patch(available in the lists posted by Marco Roeland )  , it was working fine .
> rgds
> surya

A quick reading of the patch (BTW, your MUA is mangling whitespace)
reveals it's merely creating a local variable, which should have no
bearing on code generation.

i.e. the compiler is broken.

Bad code generation can cause runtime problems too; upgrading to a
bugfixed compiler is the only sound course of action.


-- wli

Re: In fs/proc/array.c error in function proc_pid_stat

[Marco Roeland]

On Saturday December 13th 2003 William Lee Irwin III wrote:

> A quick reading of the patch (BTW, your MUA is mangling whitespace)
> reveals it's merely creating a local variable, which should have no
> bearing on code generation.

It shouldn't indeed, but it does anyway. The main fault here is some
bug that RedHat's gcc 2.96 has with dealing with 'unsigned long long'
variables. It seems to be partly triggered by the relative complexity
of the very long printf statement it's part of in this file. An earlier
patch that *only* broke up the printf (so without the local variable)
also fixed compilation for some people, though not for all. Changing
some random local variable to 'volatile' also fixed compilation.

> i.e. the compiler is broken.

It's a known *bug*, and seems to be triggered in the current 2.6.0-test
series for gcc 2.96 only in this particular function. Perhaps 'broken'
is a bit too harsh!

> Bad code generation can cause runtime problems too; upgrading to a
> bugfixed compiler is the only sound course of action.

Perhaps. But older (server) platforms with this compiler are still in
wide use, if a simple patch can make use of an otherwise reasonable
compiler again, what's the big deal. And on these platforms dual
installing two versions of gcc (and especially g++ for userspace) can
lead to other mistakes and very hard to debug artifacts from mixed
object code.
-- 
Marco Roeland, who strangely enough only uses Debian unstable himself!

Re: In fs/proc/array.c error in function proc_pid_stat

[William Lee Irwin III]

On Saturday December 13th 2003 William Lee Irwin III wrote:
>> A quick reading of the patch (BTW, your MUA is mangling whitespace)
>> reveals it's merely creating a local variable, which should have no
>> bearing on code generation.

On Sun, Dec 14, 2003 at 10:28:02AM +0100, Marco Roeland wrote:
> It shouldn't indeed, but it does anyway. The main fault here is some
> bug that RedHat's gcc 2.96 has with dealing with 'unsigned long long'
> variables. It seems to be partly triggered by the relative complexity
> of the very long printf statement it's part of in this file. An earlier
> patch that *only* broke up the printf (so without the local variable)
> also fixed compilation for some people, though not for all. Changing
> some random local variable to 'volatile' also fixed compilation.

s/fixed compilation/appeared to work around a compiler bug/


On Saturday December 13th 2003 William Lee Irwin III wrote:
>> i.e. the compiler is broken.

On Sun, Dec 14, 2003 at 10:28:02AM +0100, Marco Roeland wrote:
> It's a known *bug*, and seems to be triggered in the current 2.6.0-test
> series for gcc 2.96 only in this particular function. Perhaps 'broken'
> is a bit too harsh!

It breaks elsewhere in various ways (or has broken; maybe they update
things they still call 2.96).


On Saturday December 13th 2003 William Lee Irwin III wrote:
>> Bad code generation can cause runtime problems too; upgrading to a
>> bugfixed compiler is the only sound course of action.

On Sun, Dec 14, 2003 at 10:28:02AM +0100, Marco Roeland wrote:
> Perhaps. But older (server) platforms with this compiler are still in
> wide use, if a simple patch can make use of an otherwise reasonable
> compiler again, what's the big deal. And on these platforms dual
> installing two versions of gcc (and especially g++ for userspace) can
> lead to other mistakes and very hard to debug artifacts from mixed
> object code.

(1) I don't trust it for runtime code either; there have been problems.
(2) These idiotic rearrangements of code to work around compiler bugs
	are worthless since you'll eventually end up eventually needing
	contradictory changes to work around different compilers' bugs.
	They're also total crap changes, worthless code churn, and even
	uglify the code.
(3) 2.96? You must be kidding. Current is bordering on 3.4 if it's not
	there already. Do you think anyone's still taking patches for
	2.2.8 Linux kernels? Now apply the same reasoning to gcc. Some
	backport TLC from a distro is not going to be able to bring it
	up to modern standards.
(4) 2 versions of gcc is nothing and has zero bearing on the C++ ABI
	braindamage that went around a couple of years ago as it's not
	a C++ compiler.


-- wli

Re: In fs/proc/array.c error in function proc_pid_stat

[Marco Roeland]

On Sunday December 14th 2003 William Lee Irwin III wrote:

> > It shouldn't indeed, but it does anyway. The main fault here is some
> > bug that RedHat's gcc 2.96 has with dealing with 'unsigned long long'
> > variables. It seems to be partly triggered by the relative complexity
> > of the very long printf statement it's part of in this file. An earlier
> > patch that *only* broke up the printf (so without the local variable)
> > also fixed compilation for some people, though not for all. Changing
> > some random local variable to 'volatile' also fixed compilation.
> 
> s/fixed compilation/appeared to work around a compiler bug/

Yes, the patch is only a simple workaround, nothing clever there!

> It breaks elsewhere in various ways (or has broken; maybe they update
> things they still call 2.96).

I didn't know about the other breaks. I very much doubt that 2.96 is
still maintained.

> > Perhaps. But older (server) platforms with this compiler are still in
> > wide use, if a simple patch can make use of an otherwise reasonable
> > compiler again, what's the big deal. And on these platforms dual
> > installing two versions of gcc (and especially g++ for userspace) can
> > lead to other mistakes and very hard to debug artifacts from mixed
> > object code.
 
> (1) I don't trust it for runtime code either; there have been problems.

Ok. This particular case is a simple compile error (which is caught
easily), not a hard to debug runtime bug in code generation.

> (2) These idiotic rearrangements of code to work around compiler bugs
> 	are worthless since you'll eventually end up eventually needing
> 	contradictory changes to work around different compilers' bugs.
> 	They're also total crap changes, worthless code churn, and even
> 	uglify the code.

True, although in this particular case the code can be argued to be very
ugly already. ;-)

> (3) 2.96? You must be kidding. Current is bordering on 3.4 if it's not
> 	there already. Do you think anyone's still taking patches for
> 	2.2.8 Linux kernels? Now apply the same reasoning to gcc. Some
> 	backport TLC from a distro is not going to be able to bring it
> 	up to modern standards.

Yes this is pretty old. But if it allows people to compile and therefore
test a kernel on older systems in setups equivalent to running
production systems this also has its value. Admit that gcc 3.x is about
twice as slow as gcc 2.9x. Not everyone is a developer with multiple
testsystems and a fast compilation machine that (cross)compiles for all
of them.

> (4) 2 versions of gcc is nothing and has zero bearing on the C++ ABI
> 	braindamage that went around a couple of years ago as it's not
> 	a C++ compiler.

Yes of course, but often installing a new or dual gcc forces people
to install newer g++ and binutils which very much may break compiling
existing userspace applications.

I wholeheartedly agree that the latest compilers are a lot better, and
use them myself, but keeping on board willing testers is also *very*
valuable.

Submitting a patch for Documentation/Changes indicating that gcc 3.x is
now required might be appropriate, but I strongly think that is one of
the first actions for 2.7, not yet for 2.6.
-- 
Marco Roeland