mjw at redhat dot com | 1 Sep 14:32 2008

[Bug tapsets/6580] revamp backtrace-related tapset functions


------- Additional Comments From mjw at redhat dot com  2008-09-01 12:32 -------
caller()/ucaller() can probably be implemented more efficiently than as full
wrappers around the caller(1)/ucaller(1). For example the following currently
works to get a quick user space symbol, without need to do a full unwind (a full
unwind is necessary for getting anything more). If you just want to get the user
address and symbol (for static binaries included with -d only for now):

# Returns the address in userspace that the current task was at when the
# probe occurred.
function uaddr:long () %{ /* pure */
        #include <asm/processor.h>
        struct pt_regs *uregs;
        uregs = task_pt_regs(current);

        THIS->__retvalue = (int64_t) REG_IP(uregs);
%}

# Translates an address to a function symbol. Might be expensive
# so use sparingly in probes, try translating only in end probes.
function uaddr_symbol:string (uaddr: long) %{ /* pure */
	_stp_symbol_snprint(THIS->__retvalue, MAXSTRINGLEN, THIS->uaddr);
%}

Can be used with something like the following for a quick and dirty "profiler":

stap -d /path/to/my-static-binary -e 'probe timer.ms(100) {t = tid(); if (t !=
0) { printf("%s:.%d 0x%xd:%s\n", execname(), tid(), uaddr(),
uaddr_symbol(uaddr())); } }'

(Continue reading)

mjw at redhat dot com | 2 Sep 12:10 2008

[Bug runtime/6866] New: Extend stp_symbol_snprintf for user space

Currently stp_symbol_snprintf (and _stp_func_print, _stp_symbol_print) in
runtime/sym.c only reliably work for kernel symbols. There is a little support
for printing (static) user space executable symbols when running stap with -d
for the executable you are interested in. But that only kind of works by accident.

An executable given through -d is currently treated in main.cxx as "just"
another kernel module which is added to the systemtap_session.unwindsym_modules
vector. translate.cxx then outputs the _stp_symbol[] for a _stp_section in the
"fake" _stp_module for the binary in the stap-symbols.h file.

All the stp_symbol functions call _stp_kallsyms_lookup() which finds the closest
section and associated module, which, if the given address happens to be in user
space, will find the address associated with a user space symbol for the
executable _stp_module entry. Note that this only really works for one
executable given, so is unreliably when multiple executables can queried in a
probe. See bug #6580 comment #1 for an example of when this (kind of) works.

To make this work reliably one has to associate the _stp_module entry
(_stp_symbol table) of the executable given with -d to the actual/current
process active during the probe. Then when calling _stp_kallsyms_lookup() one
can check whether the given address is in user space and do the lookup in the
right symbol table.

The most likely candidate for this mapping would be the _stp_tf_vma_entry struct
 so we can query __stp_tf_get_vma_entry() for the current task and requested
address to get the correct symbol table. The association would be done on
__stp_tf_add_vma when the vma is file based and matches the executable
_stp_module name field.

This assumes each such executable module has just one section with symbols.
(Continue reading)

mjw at redhat dot com | 2 Sep 12:14 2008

[Bug tapsets/6580] revamp backtrace-related tapset functions


------- Additional Comments From mjw at redhat dot com  2008-09-02 10:14 -------
(In reply to comment #1)
> # Translates an address to a function symbol. Might be expensive
> # so use sparingly in probes, try translating only in end probes.
> function uaddr_symbol:string (uaddr: long) %{ /* pure */
> 	_stp_symbol_snprint(THIS->__retvalue, MAXSTRINGLEN, THIS->uaddr);
> %}
> 
> Can be used with something like the following for a quick and dirty "profiler":
> 
> stap -d /path/to/my-static-binary -e 'probe timer.ms(100) {t = tid(); if (t !=
> 0) { printf("%s:.%d 0x%xd:%s\n", execname(), tid(), uaddr(),
> uaddr_symbol(uaddr())); } }'

Franks pointed out that I should mention that _stp_symbol_snprint() only kind of
works by accident for user space and isn't reliable. I filed bug #6866 (Extend
stp_symbol_snprintf for user space) with some more explanation and a plan for
making it reliable.

--

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |6866

http://sourceware.org/bugzilla/show_bug.cgi?id=6580

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

(Continue reading)

mjw at redhat dot com | 2 Sep 12:14 2008

[Bug runtime/6866] Extend stp_symbol_snprintf for user space


--

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |6580
              nThis|                            |

http://sourceware.org/bugzilla/show_bug.cgi?id=6866

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Frank Ch. Eigler | 2 Sep 16:34 2008
Picon

pr4225 (user-space probing prototype) merged into mainline

Hi -

After a brief consultation with kenistoj last night, it seems
appropriate to merge the user-space probing work to mainline.  It is
by no means finished (several serious bugs are being worked on), but
it now causes only one feature regression: I have had to disable the
symbol-table-only probing logic.  Jim and I will restore that before
too long.

- FChE

fche at redhat dot com | 2 Sep 17:03 2008

[Bug runtime/6866] Extend stp_symbol_snprintf for user space


------- Additional Comments From fche at redhat dot com  2008-09-02 15:03 -------
At the same time, __stp_relocate() needs to learn how
to search the same table for actual relocation base
information for userspace binaries.

--

-- 

http://sourceware.org/bugzilla/show_bug.cgi?id=6866

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Om | 3 Sep 00:59 2008
Picon

Why can't I access 'kill_something_info' probes?

Hi,
I am writing some scriptlets to check trace signals. (I know about the 
signal tapset, but...)

Here is the script.

# This traces kill related syscalls
#
probe kernel.function("sys_kill")
{
	printf("%d sends %d to %d\n", pid(), $sig, $pid)
}

probe kernel.function("kill_something_info")
{
	printf("info->si_signo=%d\n", $info->si_signo)
	printf("info->si_errno=%d\n", $info->si_errno)
}
probe timer.ms(10000)
{
	exit()
}

--End of script.

Errors here...
[root <at> ... signals]# stap -vvvv ./killtrace.stp
SystemTap translator/driver (version 0.6.2/0.127 built 2008-03-27)
Copyright (C) 2005-2008 Red Hat, Inc. and others
This is free software; see the source for copying conditions.
(Continue reading)

Frank Ch. Eigler | 3 Sep 04:33 2008
Picon

Re: Why can't I access 'kill_something_info' probes?

Om <om.turyx <at> gmail.com> writes:

> I am writing some scriptlets to check trace signals. [...]

OK.

> [...]
> probe kernel.function("kill_something_info")
> {
> 	printf("info->si_signo=%d\n", $info->si_signo)
> 	printf("info->si_errno=%d\n", $info->si_errno)
> }
> [...]
> semantic error: failed to retrieve location attribute for local 'info'
> (dieoffset: 0x334d03): identifier '$info' at ./killtrace.stp:10:32
> semantic error: failed to retrieve location attribute for local 'info'
> (dieoffset: 0x334d03): identifier '$info' at ./killtrace.stp:11:32
> [...]

This is the dreaded "gcc omits debuginfo for inlined functions, especially
their parameters", aka systemtap PR 1155, and various GCC and RH bugzilla #s.

There is little one can do, except:

- try to find some other way to get at the context $info variable data,
  perhaps via a local variable within the function (requiring a statement probe),
  or by saving it from a caller site into a systemtap script-level variable
- try to place a (statement) probe into the caller of this inline function,
  where the same value may be available (perhaps under a different name)
- investigate whether a marker may be available
(Continue reading)

Wenji Huang | 3 Sep 04:37 2008
Picon

Re: Why can't I access 'kill_something_info' probes?

Om wrote:
> Hi,
> I am writing some scriptlets to check trace signals. (I know about the 
> signal tapset, but...)
> 
> Here is the script.
> 
> # This traces kill related syscalls
> #
> probe kernel.function("sys_kill")
> {
>     printf("%d sends %d to %d\n", pid(), $sig, $pid)
> }
> 
> probe kernel.function("kill_something_info")
> {
>     printf("info->si_signo=%d\n", $info->si_signo)
>     printf("info->si_errno=%d\n", $info->si_errno)
> }
> probe timer.ms(10000)
> {
>     exit()
> }
> 
> --End of script.
> 
> Errors here...
> [root <at> ... signals]# stap -vvvv ./killtrace.stp
> SystemTap translator/driver (version 0.6.2/0.127 built 2008-03-27)
> Copyright (C) 2005-2008 Red Hat, Inc. and others
(Continue reading)

Masami Hiramatsu | 3 Sep 17:26 2008
Picon

Re: [RFC PATCH 1/2] Bug Translator 3016 : Error accessing members of anonymous structs / unions

Masami Hiramatsu wrote:
> Hi Prerna,
> 
> Prerna Saxena wrote:
>> Hi all,
>> This patch modifies tapsets.cxx to enable members of anonymous structs/ 
>> unions to be recognised by the systemtap translator.
>> Pls let me know your comments..
> 
> I'm interested in this feature.
> 
> I tested your patches on x86-64 with elfutils-0.137, and I got a SEGV
> when I ran following command:
> 
> $ stap -e 'probe module("libsas").function("sas_ex_revalidate_domain") 
> {print($port_dev->ex_dev->children)}' -vvvp2

Curiously, on i386, it just shows an error.

$ stap -e 'probe module("libsas").function("sas_ex_revalidate_domain")
{print($port_dev->ex_dev->children)}' -vp2
Pass 1: parsed user script and 45 library script(s) in 300usr/0sys/307real ms.
semantic error: struct/union 'children' is being accessed instead of a member of the struct/union:
identifier '$port_dev' at <input>:2:8
Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 0 global(s) in 90usr/310sys/398real ms.
Pass 2: analysis failed.  Try again with more '-v' (verbose) options.

Actually, previous example is not correct script. :-(

And following a 'correct' script works on i386/x86-64 with your patch.
(Continue reading)


Gmane