From: H.J. L. <hon...@in...> - 2012-04-15 18:51:37
|
Hi, Linux kernel v3.4 adds x32 support whose clock_t is long long. This patch casts clock_t type to unsigned long for "%lu". H.J. --- 2012-04-15 H.J. Lu <hon...@in...> * resource.c (sys_times): Cast clock_t type to unsigned long * signal.c (printsiginfo): Likewise. --- resource.c | 6 ++++-- signal.c | 4 ++-- 3 files changed, 10 insertions(+), 4 deletions(-) create mode 100644 ChangeLog.hjl diff --git a/resource.c b/resource.c index d7a34ef..8464071 100644 --- a/resource.c +++ b/resource.c @@ -428,9 +428,11 @@ sys_times(struct tcb *tcp) tprints("{...}"); else { tprintf("{tms_utime=%lu, tms_stime=%lu, ", - tbuf.tms_utime, tbuf.tms_stime); + (unsigned long) tbuf.tms_utime, + (unsigned long) tbuf.tms_stime); tprintf("tms_cutime=%lu, tms_cstime=%lu}", - tbuf.tms_cutime, tbuf.tms_cstime); + (unsigned long) tbuf.tms_cutime, + (unsigned long) tbuf.tms_cstime); } } return 0; diff --git a/signal.c b/signal.c index ab7ae56..ff61360 100644 --- a/signal.c +++ b/signal.c @@ -723,8 +723,8 @@ printsiginfo(siginfo_t *sip, int verbose) tprints(", ..."); else tprintf(", si_utime=%lu, si_stime=%lu", - sip->si_utime, - sip->si_stime); + (unsigned long) sip->si_utime, + (unsigned long) sip->si_stime); break; case SIGILL: case SIGFPE: case SIGSEGV: case SIGBUS: -- 1.7.6.5 |
From: Mike F. <va...@ge...> - 2012-04-15 19:02:47
Attachments:
signature.asc
|
On Sunday 15 April 2012 14:17:13 H.J. Lu wrote: > Linux kernel v3.4 adds x32 support whose clock_t is long long. This > patch casts clock_t type to unsigned long for "%lu". shouldn't we cast it to long long then and use %llu ? -mike |
From: H.J. L. <hjl...@gm...> - 2012-04-15 20:22:12
|
On Sun, Apr 15, 2012 at 12:03 PM, Mike Frysinger <va...@ge...> wrote: > On Sunday 15 April 2012 14:17:13 H.J. Lu wrote: >> Linux kernel v3.4 adds x32 support whose clock_t is long long. This >> patch casts clock_t type to unsigned long for "%lu". > > shouldn't we cast it to long long then and use %llu ? It also works for x32. I don't think it makes a difference in practice. I doubt clock_t value returns by those system calls can overflow 32bit integer. Thanks. -- H.J. |
From: Denys V. <dvl...@re...> - 2012-04-16 09:59:01
|
On 04/15/2012 10:22 PM, H.J. Lu wrote: > On Sun, Apr 15, 2012 at 12:03 PM, Mike Frysinger<va...@ge...> wrote: >> On Sunday 15 April 2012 14:17:13 H.J. Lu wrote: >>> Linux kernel v3.4 adds x32 support whose clock_t is long long. This >>> patch casts clock_t type to unsigned long for "%lu". >> >> shouldn't we cast it to long long then and use %llu ? > > It also works for x32. > > I don't think it makes a difference in practice. I doubt clock_t value returns > by those system calls can overflow 32bit integer. It probably won't - modulo bugs. And strace is a _debugging_ tool. It might be used exactly because someone chases a bug. Let's show the user the full, non-truncated value. -- vda |
From: Mike F. <va...@ge...> - 2012-04-15 20:30:16
Attachments:
signature.asc
|
On Sunday 15 April 2012 16:22:06 H.J. Lu wrote: > On Sun, Apr 15, 2012 at 12:03 PM, Mike Frysinger <va...@ge...> wrote: > > On Sunday 15 April 2012 14:17:13 H.J. Lu wrote: > >> Linux kernel v3.4 adds x32 support whose clock_t is long long. This > >> patch casts clock_t type to unsigned long for "%lu". > > > > shouldn't we cast it to long long then and use %llu ? > > It also works for x32. > > I don't think it makes a difference in practice. I doubt clock_t value > returns by those system calls can overflow 32bit integer. famous last words! seriously though, if clock_t is known to be 64bits, then we should be decoding it accordingly. otherwise, i'd question why it was declared 64bits in the first place instead of keeping it as 32. -mike |
From: H.J. L. <hjl...@gm...> - 2012-04-15 20:49:55
|
On Sun, Apr 15, 2012 at 1:30 PM, Mike Frysinger <va...@ge...> wrote: > On Sunday 15 April 2012 16:22:06 H.J. Lu wrote: >> On Sun, Apr 15, 2012 at 12:03 PM, Mike Frysinger <va...@ge...> wrote: >> > On Sunday 15 April 2012 14:17:13 H.J. Lu wrote: >> >> Linux kernel v3.4 adds x32 support whose clock_t is long long. This >> >> patch casts clock_t type to unsigned long for "%lu". >> > >> > shouldn't we cast it to long long then and use %llu ? >> >> It also works for x32. >> >> I don't think it makes a difference in practice. I doubt clock_t value >> returns by those system calls can overflow 32bit integer. > > famous last words! > > seriously though, if clock_t is known to be 64bits, then we should be decoding > it accordingly. otherwise, i'd question why it was declared 64bits in the > first place instead of keeping it as 32. We want to use the same "times" system call for both x32 and x86-64. Since times use "clock_t", we changed x32 clock_t from 32bit to 64bit. -- H.J. |
From: H.J. L. <hon...@in...> - 2012-04-16 14:40:25
|
On Sun, Apr 15, 2012 at 11:17:13AM -0700, H.J. Lu wrote: > > Hi, > > Linux kernel v3.4 adds x32 support whose clock_t is long long. This > patch casts clock_t type to unsigned long for "%lu". > > H.J. > --- > Here is a patch to case clock_t type to unsigned long long. Thanks. H.J. --- 2012-04-16 H.J. Lu <hon...@in...> * resource.c (sys_times): Cast clock_t type to unsigned long long. diff --git a/resource.c b/resource.c index d7a34ef..f0e2992 100644 --- a/resource.c +++ b/resource.c @@ -427,10 +427,12 @@ sys_times(struct tcb *tcp) else if (umove(tcp, tcp->u_arg[0], &tbuf) < 0) tprints("{...}"); else { - tprintf("{tms_utime=%lu, tms_stime=%lu, ", - tbuf.tms_utime, tbuf.tms_stime); - tprintf("tms_cutime=%lu, tms_cstime=%lu}", - tbuf.tms_cutime, tbuf.tms_cstime); + tprintf("{tms_utime=%llu, tms_stime=%llu, ", + (unsigned long long) tbuf.tms_utime, + (unsigned long long) tbuf.tms_stime); + tprintf("tms_cutime=%llu, tms_cstime=%llu}", + (unsigned long long) tbuf.tms_cutime, + (unsigned long long) tbuf.tms_cstime); } } return 0; |
From: Mike F. <va...@ge...> - 2012-04-16 15:11:43
Attachments:
signature.asc
|
On Monday 16 April 2012 10:39:58 H.J. Lu wrote: > On Sun, Apr 15, 2012 at 11:17:13AM -0700, H.J. Lu wrote: > > Linux kernel v3.4 adds x32 support whose clock_t is long long. This > > patch casts clock_t type to unsigned long for "%lu". > > Here is a patch to case clock_t type to unsigned long long. Acked-by: Mike Frysinger <va...@ge...> -mike |
From: Dmitry V. L. <ld...@al...> - 2012-04-16 15:14:45
|
Hi, On Mon, Apr 16, 2012 at 07:39:58AM -0700, H.J. Lu wrote: > On Sun, Apr 15, 2012 at 11:17:13AM -0700, H.J. Lu wrote: > > > > Linux kernel v3.4 adds x32 support whose clock_t is long long. This > > patch casts clock_t type to unsigned long for "%lu". > > > > H.J. > > --- > > Here is a patch to case clock_t type to unsigned long long. What about other cases where clock_t type is printed? -- ldv |
From: H.J. L. <hjl...@gm...> - 2012-04-16 15:31:57
Attachments:
strace-clock_t.patch
|
On Mon, Apr 16, 2012 at 8:14 AM, Dmitry V. Levin <ld...@al...> wrote: > Hi, > > On Mon, Apr 16, 2012 at 07:39:58AM -0700, H.J. Lu wrote: >> On Sun, Apr 15, 2012 at 11:17:13AM -0700, H.J. Lu wrote: >> > >> > Linux kernel v3.4 adds x32 support whose clock_t is long long. This >> > patch casts clock_t type to unsigned long for "%lu". >> > >> > H.J. >> > --- >> >> Here is a patch to case clock_t type to unsigned long long. > > What about other cases where clock_t type is printed? > > Here is a patch to use unsigned long long for clock_t in resource.c and signal.c -- H.J. |
From: Dmitry V. L. <ld...@al...> - 2012-04-17 02:55:05
|
On Mon, Apr 16, 2012 at 08:31:46AM -0700, H.J. Lu wrote: > On Mon, Apr 16, 2012 at 8:14 AM, Dmitry V. Levin wrote: > > On Mon, Apr 16, 2012 at 07:39:58AM -0700, H.J. Lu wrote: > >> On Sun, Apr 15, 2012 at 11:17:13AM -0700, H.J. Lu wrote: > >> > > >> > Linux kernel v3.4 adds x32 support whose clock_t is long long. This > >> > patch casts clock_t type to unsigned long for "%lu". > >> > > >> > H.J. > >> > --- > >> > >> Here is a patch to case clock_t type to unsigned long long. > > > > What about other cases where clock_t type is printed? > > Here is a patch to use unsigned long long for clock_t in resource.c > and signal.c Thanks, applied. -- ldv |