public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Wenji Huang <wenji.huang@oracle.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: systemTAP <systemtap@sources.redhat.com>
Subject: Re: Too larger number in badkprobe test on 32 bits machine.
Date: Fri, 09 Jan 2009 02:32:00 -0000	[thread overview]
Message-ID: <4966B66B.5070301@oracle.com> (raw)
In-Reply-To: <y0mhc4cjuau.fsf@ton.toronto.redhat.com>

Frank Ch. Eigler wrote:
> Wenji Huang <wenji.huang@oracle.com> writes:
> 
>> [...]
>> kernel.statement(-1).absolute {} probe timer.s(1) { exit() }'
>> [...]
>> /tmp/staplt6ZIz/stap_84012a21d1a75884e8298817a3e8ad51_390.c:235:
>> warning: integer constant is too large for 'unsigned long' type
>> /tmp/staplt6ZIz/stap_84012a21d1a75884e8298817a3e8ad51_390.c:235:
>> warning: large integer implicitly truncated to unsigned type
>> make[1]: ***
>> [...]
>> Seems "-1" is interpreted as 64-bit number and not appropriate for 32
>> bits machine. Change to other number or update translate.cxx to
>> perform explicitly truncation ?
> 
> Yeah, translate.cxx could do it - the trick is finding a series of
> casts that quietly truncates the value.  (Changing the test case to
> some other number like 0 would only paper over the problem.)
> 
> - FChE
> 
Seems the following patch can solve the problem.
diff --git a/tapsets.cxx b/tapsets.cxx
index 20bea45..abc0fae 100644
--- a/tapsets.cxx
+++ b/tapsets.cxx
@@ -5039,7 +5039,7 @@ dwarf_derived_probe_group::emit_module_decls 
(systemtap_session& s)
            assert (p->maxactive_val >= 0 && p->maxactive_val <= USHRT_MAX);
            s.op->line() << " .maxactive_val=" << p->maxactive_val << ",";
          }
-      s.op->line() << " .address=0x" << hex << p->addr << dec << "UL,";
+      s.op->line() << " .address=(unsigned long)0x" << hex << p->addr 
<< dec << "ULL,";
        s.op->line() << " .module=\"" << p->module << "\",";
        s.op->line() << " .section=\"" << p->section << "\",";
        s.op->line() << " .pp=" << lex_cast_qstring 
(*p->sole_location()) << ",";

Did some tests on x86 and x86_64. The good result is achieved. Probe 
kernel.statement(0x123456789) will be truncated into 
kernel.statement(0x12345678) on 32 bits machine.
$ uname -mr
2.6.26 i686
$ sudo stap -g -w -e 'probe kernel.statement(-1).absolute {}probe 
timer.s(1) { exit() }'
WARNING: probe kernel.statement(-1).absolute registration error (rc -22)

Regards,
Wenji

      reply	other threads:[~2009-01-09  2:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-06  8:49 Wenji Huang
2009-01-06 16:04 ` Frank Ch. Eigler
2009-01-09  2:32   ` Wenji Huang [this message]

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=4966B66B.5070301@oracle.com \
    --to=wenji.huang@oracle.com \
    --cc=fche@redhat.com \
    --cc=systemtap@sources.redhat.com \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).