[Bug translator/16589] New: Use elfutils libdw dwarf_getlocations () to pick better probe point to access vars

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

https://sourceware.org/bugzilla/show_bug.cgi?id=16589

            Bug ID: 16589
           Summary: Use elfutils libdw dwarf_getlocations () to pick
                    better probe point to access vars
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: mjw at redhat dot com

elfutils 0.157 comes with a new function dwarf_getlocations () that enumerate
the locations ranges and descriptions covered by a given attribute. This could
help in situations like the following (seen on some ppc64 kernel probes):

semantic error: not accessible at this address [man error::dwarf]
(0xc0000000002091e4, dieoffset: 0x104eb65): identifier '$p'
at /usr/local/share/systemtap/tapset/linux/memory.stp:245:12

That DIE is:

 [104eb65]        formal_parameter
                 abstract_origin      (ref4) [104a651]
                 location             (sec_offset) location list [57cc07]

The origin is:

 [104a651]      formal_parameter
               name                 (string) "p"
               decl_file            (data1) 7
               decl_line            (data2) 402
               type                 (ref4) [103f972]

It is an argument of the inlined_subroutine at [104eb0e] with as origin
[104a644] which is:

 [104a644]    subprogram
             external             (flag_present) Yes
             name                 (strp) "oom_kill_process"
             decl_file            (data1) 7
             decl_line            (data2) 402
             prototyped           (flag_present) Yes
             inline               (data1) inlined (1)

It is inlined a couple of times in that CU.

The location list [57cc07] says:

 [57cc07]  +0x00000000002091ec..+0x0000000000209234 [   0] reg3
           +0x00000000002092d0..+0x00000000002092d4 [   0] reg3
           +0x00000000002092d4..+0x00000000002092db [   0] reg9
           +0x0000000000209360..+0x000000000020937f [   0] reg3

we are trying to get the location at 2091e4, which is a little before
the first range.

So one thing that we could possibly do in these situations where GCC didn't
produce a location expression at the address we are interested in is to
use the dwarf_getlocations () function to try to pick a better probe point at
an address where there is a location entry defined.

The only thing making that slight more difficult is that we detect this issue
fairly late, so it might take a bit of work to retry the probe at a different
address. And we would have to check/warn the address is still close to where
the user would have liked it.

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