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.
next prev parent 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).