Re: [Bug runtime/14026] inode based uprobes print_ubacktrace doesn't resolve the symbol name

[Mark Wielaard <mjw at redhat dot com>]

On Mon, 2012-07-23 at 11:27 +0530, Srikar Dronamraju wrote:
> > --- Comment #24 from Frank Ch. Eigler <fche at redhat dot com> 2012-07-19 14:53:23 UTC ---
> > This inode-uprobes shortcoming is biting other users too.  Perhaps we can work
> > around it in stap land by using the mmap callbacks that check build-ids to also
> > go and calculate run-time virtual addresses of the inode-uprobes, so they can
> > be filled in around probe execution time.
> > 
> 
> Can you please elaborate on whats the shortcoming?

The issue is that probe handlers (and various parts of the systemtap
runtime) assume they have access to the exact REG_IP where the program
was probed. At least on x86 architectures there is an off-by-one because
the IP is increased before the probe handler is called. This results in
the probe handler (and unwinder) not knowing exactly where they are. In
some cases that leads to errors since the IP spilled over into the next
function (in which case the runtime cannot find the correct CFI).

With kprobes and utrace-uprobes tapsets.cxx works around this by doing
the following:

  // Make it look like the IP is set as it would in the actual user
  // task when calling real probe handler. Reset IP regs on return, so
  // we don't confuse uprobes. PR10458
  s.op->newline() << "{";
  s.op->indent(1);
  s.op->newline() << "unsigned long uprobes_ip = REG_IP(c->uregs);";
  s.op->newline() << "SET_REG_IP(regs, inst->vaddr);";
  s.op->newline() << "(*sups->probe->ph) (c);";
  s.op->newline() << "SET_REG_IP(regs, uprobes_ip);";
  s.op->newline(-1) << "}";

We need something similar for inode-uprobes, because currently it has:

  // XXX: Can't set SET_REG_IP; we don't actually know the relocated address.
  // ...  In some error cases, uprobes itself calls uprobes_get_bkpt_addr().

PR10458 - uaddr() returns one past current instruction for uprobes, has
more background: http://sourceware.org/bugzilla/show_bug.cgi?id=10458

Cheers,

Mark