Bug 13296 - inaccessible sdt.h operands of the form symbol(%reg)
Summary: inaccessible sdt.h operands of the form symbol(%reg)
Status: RESOLVED FIXED
Alias: None
Product: systemtap
Classification: Unclassified
Component: translator (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
URL:
Keywords:
: 12690 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-10-14 12:14 UTC by Frank Ch. Eigler
Modified: 2014-05-09 20:39 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Ch. Eigler 2011-10-14 12:14:52 UTC
We have encountered cases where the compiler emits assembler operands
for sdt.h parameters that cannot possibly be processed by stap (like
in the case of referring to local labels that are lost during the
compilation/linking stage).  The cure for that has been to use
something like -DSTAP_SDT_ARG_CONSTRAINT=r to force values into
registers.

However, we should at least attempt to resolve globals in the symbol
table, within sdt_uprobe_var_expanding_visitor::visit_target_symbol_arg.
Comment 1 Frank Ch. Eigler 2011-10-14 12:35:34 UTC
readelf -x .note.stapsdt bash-prev                

Hex dump of section '.note.stapsdt':
  0x00000000 08000000 53000000 03000000 73746170 ....S.......stap
  0x00000010 73647400 791e4300 00000000 6af74b00 sdt.y.C.....j.K.
  0x00000020 00000000 70fc6d00 00000000 62617368 ....p.m.....bash
  0x00000030 00626173 685f6675 6e637469 6f6e5f63 .bash_function_c
  0x00000040 616c6c00 2d34406c 696e655f 6e756d62 all.-4@line_numb
  0x00000050 65722825 72697029 20384025 72736920 er(%rip) 8@%rsi 
  0x00000060 38402572 62700000                   8@%rbp..

nm bash-prev| grep line_number
000000000042df70 T executing_line_number
00000000006e12e0 b function_line_number
00000000006dfdb4 B line_number
00000000006dfdb0 B line_number_base
00000000006e12d8 b line_number_for_err_trap
Comment 2 Mark Wielaard 2011-10-18 13:17:52 UTC
(In reply to comment #0)
> However, we should at least attempt to resolve globals in the symbol
> table, within sdt_uprobe_var_expanding_visitor::visit_target_symbol_arg.

Note we already have dwflpp::vardie_from_symtable() to do that.
Comment 3 Frank Ch. Eigler 2011-12-01 02:50:24 UTC
*** Bug 12690 has been marked as a duplicate of this bug. ***
Comment 4 Jonathan Lebon 2014-05-05 20:24:02 UTC
The branch jlebon/pr13296 contains patches to support this now. More precisely, we also pick up STT_OBJECT symbols from the symbol table, which we then try to use if we meet such an operand.

Example:

$ cat prog.c

#include "sys/sdt.h"

int globalvar = 3;

int main(int argc, char **argv)
{
   globalvar += argc;
   STAP_PROBE1(test, mymark, globalvar);
   return 0;
}
$ gcc prog.c -o prog -I../install/include -DSTAP_SDT_ARG_CONSTRAINT=m
$ readelf --notes prog | tail -n 7
Notes at offset 0x00001088 with length 0x0000004c:
  Owner                 Data size       Description
  stapsdt              0x00000037       NT_STAPSDT (SystemTap probe descriptors)
    Provider: test
    Name: mymark
    Location: 0x000000000040050c, Base: 0x00000000004005b0, Semaphore: 0x0000000000000000
    Arguments: -4@globalvar(%rip)
$ stap -e 'probe process.mark("mymark") { printf("globalvar is %d\n", $arg1) }' -c ./prog
globalvar is 4
$
Comment 5 Jonathan Lebon 2014-05-09 20:39:13 UTC
Merged into master under commit b8688ee.