All of lore.kernel.org
 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 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.