public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* [Bug translator/16596] New: Support DW_OP_GNU_entry_value in location expressions
@ 2014-02-15 23:05 mjw at redhat dot com
  2014-02-19 20:59 ` [Bug translator/16596] " jlebon at redhat dot com
                   ` (9 more replies)
  0 siblings, 10 replies; 11+ messages in thread
From: mjw at redhat dot com @ 2014-02-15 23:05 UTC (permalink / raw)
  To: systemtap

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

            Bug ID: 16596
           Summary: Support DW_OP_GNU_entry_value in location expressions
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: mjw at redhat dot com

Newer GCC releases might produce DWARF location expressions for more arguments
or variables using DW_OP_GNU_entry_value. loc2c currently doesn't support such
location expressions. The description of DW_OP_GNU_entry_value (as DWARF5
extension) can be found at http://dwarfstd.org/ShowIssue.php?issue=100909.1

DW_OP_GNU_entry_value provides an DWARF expression (that can be retrieved
through dwarf_getlocation_attr in libdw elfutils 0.157+ as a location
attribute). Any register op used in the DW_OP_GNU_entry_value expression needs
to be evaluated as the value that register had upon entering the subprogram.

Getting the value of the register at the start of the subprogram can be done in
several ways.

If the register was used to pass an argument to the function then it might be
retrieved through finding the DW_TAG_call_site with DW_AT_low_pc pointing to
the function. The DW_TAG_call_site_parameter with a DW_AT_location of the
register will have as value the DW_AT_GNU_call_site_value. Note that this
location expression itself might use registers that need to be evaluated in the
caller frame (so might need an unwind step, which might fail to restore the
value if that register was caller-saved). Since there might be multiple call
sites the found value depends on the return address of the current function at
runtime (so might need a lookup table at runtime).

If the register was callee saved it should be possible to retrieve the value of
the register on function entry through CFI. This might be possible at
translation time using dwarf_cfi_addrframe and dwarf_frame_register.

Finally the needed registers can be collected by introducing an extra probe at
the first instruction of the subprogram. That probe stores the needed registers
as thread local values that can be retrieved by the probe later in the function
that might need them. This might also need an extra retprobe on the function to
delete the copy of the registers again.

Some example location expressions using DW_OP_GNU_entry_value can be found in
the elfutils tests/run-varlocs.sh.

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

^ permalink raw reply	[flat|nested] 11+ messages in thread
end of thread, other threads:[~2018-11-13 16:08 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-15 23:05 [Bug translator/16596] New: Support DW_OP_GNU_entry_value in location expressions mjw at redhat dot com
2014-02-19 20:59 ` [Bug translator/16596] " jlebon at redhat dot com
2014-03-05 16:42 ` dsmith at redhat dot com
2014-03-10  9:41 ` mjw at redhat dot com
2014-03-13 17:14 ` mjw at redhat dot com
2014-03-14  8:50 ` mjw at redhat dot com
2016-05-24 18:17 ` fche at redhat dot com
2017-05-15 19:49 ` jistone at redhat dot com
2017-05-15 19:50 ` jistone at redhat dot com
2017-09-12 17:10 ` dsmith at redhat dot com
2018-11-13 16:08 ` fche at redhat dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).