From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17490 invoked by alias); 1 Sep 2005 15:01:00 -0000 Mailing-List: contact systemtap-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sources.redhat.com Received: (qmail 17171 invoked by uid 22791); 1 Sep 2005 15:00:43 -0000 Date: Thu, 01 Sep 2005 15:01:00 -0000 From: "Frank Ch. Eigler" To: Martin Hunt Cc: systemtap@sources.redhat.com Subject: Re: lots of systemtap language questions Message-ID: <20050901150038.GB9569@redhat.com> References: <1125547048.11102.21.camel@dragon> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: <1125547048.11102.21.camel@dragon> User-Agent: Mutt/1.4.1i X-SW-Source: 2005-q3/txt/msg00415.txt.bz2 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 1886 Hi - hunt wrote: > [...] > > > Whichever we pick, should the basic builtins have some common prefix? > > > Or we just have pid(), caller(), pid(), ppid(), gid(), stack(), etc? > > > > I suggest going for simple names for the obvious ones ("caller" and > > "stack" are not quite as obvious as the others). >=20 > Hmm. How about calling_function(), calling_address() and backtrace()? Good. > [...] > stack() - should be backtrace()? Yeah. > print_regs() - register dump > Maybe I should call everything that prints directly print_xxx()? The > rest of the functions return ints or strings. Yes, good idea. > I've also done print(), which is like log() except uses _stp_print() [...] OK. It would be great to have a few lines of documentation in the stapfuncs.5 man page for each of these functions, and a buildok test to verify that script code using them compiles. > > With the current MAXSTRINGLEN value, that > > should be enough for a dozen levels.=20=20 >=20 > Seven levels on 64-bit archs and you lose at least 2 or 3 of those due=20 > to duplicate info because our backtraces are really only dumps of > addresses on the stack that appear to be function addresses. On a 64-bit host, the default MAXSTRINGLEN could increase. > (Due to the lack of a frame pointer, that's all we can do right > now.) When we start supporting user-level code, we may have to bite the bullet and support real stack frame unwinding, perhaps by transcribing the dwarf unwind data into the probe program. Or we may have to propagate the hack to user space. We certainly won't be able to require people to stop using -fomit-frame-pointers. > I'll have to implement a special function to turn those addresses > into a stack trace at probe exit. [...] How do you envision this working? stpd post-processing trace data? "probe end {}" script code calling this special function? - FChE --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature Content-Disposition: inline Content-length: 189 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDFxeWVZbdDOm/ZT0RAsaUAJ0SqP3Mqb+qpA22M/Wrhs/JXg46YACeNQWu RbUYE2TdsCrLvasws1xwAy4= =dIZd -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY--