public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
To: William Cohen <wcohen@redhat.com>
Cc: "Frank Ch. Eigler" <fche@redhat.com>,
	srinivasa@in.ibm.com,         systemtap@sources.redhat.com
Subject: Re: changelog files, %( %) idioms
Date: Thu, 06 Mar 2008 15:16:00 -0000	[thread overview]
Message-ID: <20080306151631.GA6705@in.ibm.com> (raw)
In-Reply-To: <47D0043E.90502@redhat.com>

On Thu, Mar 06, 2008 at 09:48:30AM -0500, William Cohen wrote:
> Ananth N Mavinakayanahalli wrote:
>> On Mon, Mar 03, 2008 at 11:48:13AM -0500, William Cohen wrote:
>>> Frank Ch. Eigler wrote:
>>>> Hi -
>>>>
>>>> On Mon, Mar 03, 2008 at 05:48:41PM +0530, Ananth N Mavinakayanahalli wrote:
>>>>> [...]
>>>>>  probe syscall.sigaltstack = kernel.function("sys_sigaltstack") {
>>>>>  	name = "sigaltstack"
>>>>> -	ebx = $ebx
>>>>> -	argstr = sprintf("%p", $ebx)
>>>>> +	bx = %( kernel_vr > "2.6.24" %? $bx %: $ebx %)
>>>>> +	argstr = sprintf("%p", %( kernel_vr > "2.6.24" %? $bx %: $ebx %) )
>>>> I suggest picking a single more informative variable name than "ebx"
>>>> or "bx" for that parameter.  Then that variable could be used as the
>>>> plain sprintf value.
>>>>
>>>> - FChE
>>> I saw this this cause failure on F-9 i686. There could be 2.6.24.1, so 
>>> probably want to check that the kernel is earlier than 2.6.25. Something 
>>> like the following:
>>
>> Actually, this went into 2.6.25-rc
>>
>>> bx = %( kernel_vr < "2.6.25" %? $bx %: $ebx %)
>>>
>>> Could the use of $bx be factored out of argstr, so there is only one 
>>> check for the kernel version for $ebx/$bx rather than two?
>>
>> How does this look?
>>
>> ---
>>  tapset/i686/syscalls.stp |    4 ++--
>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> Index: systemtap-4mar/tapset/i686/syscalls.stp
>> ===================================================================
>> --- systemtap-4mar.orig/tapset/i686/syscalls.stp
>> +++ systemtap-4mar/tapset/i686/syscalls.stp
>> @@ -119,8 +119,8 @@ probe syscall.set_zone_reclaim.return =
>>  #
>>  probe syscall.sigaltstack = kernel.function("sys_sigaltstack") {
>>  	name = "sigaltstack"
>> -	ebx = $ebx
>> -	argstr = sprintf("%p", $ebx)
>> +	ussp = %( kernel_vr < "2.6.25" %? $ebx %: $bx %)
>> +	argstr = sprintf("%p", ussp)
>>  }
>>  probe syscall.sigaltstack.return = kernel.function("sys_sigaltstack").return {
>>  	name = "sigaltstack"
>
> That looks okay.

Patch committed.

Thanks,
Ananth

  reply	other threads:[~2008-03-06 15:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-25 15:00 Frank Ch. Eigler
2008-03-03 12:18 ` Ananth N Mavinakayanahalli
2008-03-03 16:24   ` Frank Ch. Eigler
2008-03-03 16:48     ` William Cohen
2008-03-04  4:29       ` Ananth N Mavinakayanahalli
2008-03-06 14:48         ` William Cohen
2008-03-06 15:16           ` Ananth N Mavinakayanahalli [this message]
2008-03-06  9:10 ` examples/wait4time.stp Wenji Huang

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=20080306151631.GA6705@in.ibm.com \
    --to=ananth@in.ibm.com \
    --cc=fche@redhat.com \
    --cc=srinivasa@in.ibm.com \
    --cc=systemtap@sources.redhat.com \
    --cc=wcohen@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).