[Bug uprobes/14882] bring back process("$LIBRARY").statement("$ADDRESS")

["jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

Josh Stone <jistone at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jistone at redhat dot com

--- Comment #2 from Josh Stone <jistone at redhat dot com> 2012-11-27 18:04:49 UTC ---
There are a few things going on.

First, as Frank mentioned, the address should be given as a plain number, not a
string.  A statement("STRING") is parsed as a function name, usually with
@FILE:LINE too.  Since function names can't start with numbers (at least in
C/C++), we could possibly be clever and treat statement("0xabc") as an address,
or at least warn that it's probably not what you intended.

The second thing is that the address needs to be valid according to the file's
current relocations.  So with Adrian's address, which from IRC I gather was
read from /proc/PID/maps, that's most likely an ASLR-munged address.  Frank's
address is probably just plain invalid for an EXEC binary.  A couple of
examples:

> $ nm ./stap | grep -w main
> 000000000040ed50 T main
> $ stap -l 'process("./stap").statement(0x40ed50)' 
> process("/home/jistone/systemtap/build/stap").statement(0x40ed50)

> $ nm -D /lib64/libelf.so.1 | grep -w elf_begin
> 0000003279c042f0 T elf_begin
> $ stap -l 'process("/lib64/libelf.so.1").statement(0x3279c042f0)'
> process("/usr/lib64/libelf-0.154.so").statement(0x3279c042f0)

In both of your error cases, you actually clipped the simple error result. 
Whether the address is wrongly as a string, or just invalid, you get:

> $ stap -p4 -e 'probe process("./stap").statement("0xbfdf") {}'
> semantic error: while resolving probe point: identifier 'process' at > <input>:1:7
>         source: probe process("./stap").statement("0xbfdf") {}
>                       ^
> 
> semantic error: no match
> Pass 2: analysis failed.  Try again with another '--vp 01' option.

We have an inversion between the error "no match" and the location reporting,
and the extra blank line between doesn't help either.  I've noticed this in a
few scenarios, but I'm not sure if this is a recent change.  I think having
that error message *before* the location will clarify at least a little. 
Another example:

> $ stap -p4 -e 'probe process(1).statement(0xf00).absolute {}'
> semantic error: while resolving probe point: identifier 'process' at <input>:1:7
>         source: probe process(1).statement(0xf00).absolute {}
>                       ^
> 
> semantic error: absolute process probes not available with inode-based uprobes

This was the mode you would use for /proc/PID/maps sort of addresses, but that
only worked with the old address-based uprobes.  It might be possible to make
the new inode+offset uprobes deal with this by walking the VM at runtime, and
then if the address has an inode (i.e. is not anon memory), we can figure out
the offset and call uprobes.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.