linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marco Roeland <marco.roeland@xs4all.nl>
To: ndiamond@wta.att.ne.jp
Cc: Linux Kernel Development <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] RH7.3 can't compile 2.6.0-test8 (fs/proc/array.c)
Date: Thu, 23 Oct 2003 09:48:10 +0200	[thread overview]
Message-ID: <20031023074810.GA1809@localhost> (raw)
In-Reply-To: <20031023011658.9B576E1EA@smtp3.att.ne.jp>

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.


  reply	other threads:[~2003-10-23  7:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-23  1:16 [PATCH] RH7.3 can't compile 2.6.0-test8 (fs/proc/array.c) ndiamond
2003-10-23  7:48 ` Marco Roeland [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-10-21 13:19 RH7.3 can't compile 2.6.0-test8 rwhron
2003-10-21 13:52 ` Marco Roeland
2003-10-21 14:37   ` [PATCH] RH7.3 can't compile 2.6.0-test8 (fs/proc/array.c) Marco Roeland
2003-10-21 20:12     ` Paul Larson
2003-10-21 20:46     ` bill davidsen
2003-10-22 10:36     ` Norman Diamond

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=20031023074810.GA1809@localhost \
    --to=marco.roeland@xs4all.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ndiamond@wta.att.ne.jp \
    /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;
as well as URLs for NNTP newsgroup(s).