From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19375 invoked by alias); 9 Aug 2016 13:54:31 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 19349 invoked by uid 89); 9 Aug 2016 13:54:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*M:stream, Hx-languages-length:1066, H*F:U*mjw, H*i:sk:b9cc273 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 09 Aug 2016 13:54:29 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8B6AA81112; Tue, 9 Aug 2016 13:54:28 +0000 (UTC) Received: from stream.wildebeest.org (ovpn-116-49.ams2.redhat.com [10.36.116.49]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u79DsR6N010425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 Aug 2016 09:54:28 -0400 Received: by stream.wildebeest.org (Postfix, from userid 1000) id 0CAA9FFA41; Tue, 9 Aug 2016 13:25:01 +0200 (CEST) Date: Tue, 09 Aug 2016 13:54:00 -0000 From: Mark Wielaard To: Avi Kivity Cc: David Smith , systemtap@sourceware.org Subject: Re: Some newbie questions Message-ID: <20160809112501.GK2508@stream> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.2 (2016-07-01) X-SW-Source: 2016-q3/txt/msg00142.txt.bz2 On Tue, Aug 09, 2016 at 09:51:22AM +0300, Avi Kivity wrote: > On 08/08/2016 05:58 PM, David Smith wrote: > > 2) Your ubacktrace() call in the timer function isn't going to report > > what you want. At that point, you aren't running in the context of the > > process, you are running in the context of whatever kernel thread is > > running the timer. I'm really sure what a user backtrace will report at > > that point, but it certainly won't be useful. > > Actually I got good backtraces when I instrumented a task to spin for 100ms. > I also got some bad traces, but did not investigate more. stap does indeed try to make this work even from a kernel context. See runtime/stack.c: /** Gets user space registers when available, also sets context * full_uregs_p if appropriate. Should be used instead of accessing * context uregs field directly when (full) uregs are needed from * kernel context. */ static struct pt_regs *_stp_get_uregs(struct context *c) But it might indeed depend on architecture and timer probe used. Cheers, Mark