]>
Commit | Line | Data |
---|---|---|
c63539ff ML |
1 | .. |
2 | Copyright 1988-2022 Free Software Foundation, Inc. | |
3 | This is part of the GCC manual. | |
4 | For copying conditions, see the copyright.rst file. | |
5 | ||
6 | .. index:: GIMPLE_DEBUG, GIMPLE_DEBUG_BIND, GIMPLE_DEBUG_BEGIN_STMT, GIMPLE_DEBUG_INLINE_ENTRY | |
7 | ||
8 | .. _gimple_debug: | |
9 | ||
10 | GIMPLE_DEBUG | |
11 | ^^^^^^^^^^^^ | |
12 | ||
13 | .. function:: gdebug *gimple_build_debug_bind (tree var, tree value, gimple stmt) | |
14 | ||
15 | Build a ``GIMPLE_DEBUG`` statement with ``GIMPLE_DEBUG_BIND`` | |
16 | ``subcode``. The effect of this statement is to tell debug | |
17 | information generation machinery that the value of user variable | |
18 | ``var`` is given by ``value`` at that point, and to remain with | |
19 | that value until ``var`` runs out of scope, a | |
20 | dynamically-subsequent debug bind statement overrides the binding, or | |
21 | conflicting values reach a control flow merge point. Even if | |
22 | components of the ``value`` expression change afterwards, the | |
23 | variable is supposed to retain the same value, though not necessarily | |
24 | the same location. | |
25 | ||
26 | It is expected that ``var`` be most often a tree for automatic user | |
27 | variables (``VAR_DECL`` or ``PARM_DECL``) that satisfy the | |
28 | requirements for gimple registers, but it may also be a tree for a | |
29 | scalarized component of a user variable (``ARRAY_REF``, | |
30 | ``COMPONENT_REF``), or a debug temporary (``DEBUG_EXPR_DECL``). | |
31 | ||
32 | As for ``value``, it can be an arbitrary tree expression, but it is | |
33 | recommended that it be in a suitable form for a gimple assignment | |
34 | ``RHS``. It is not expected that user variables that could appear | |
35 | as ``var`` ever appear in ``value``, because in the latter we'd | |
36 | have their ``SSA_NAME`` s instead, but even if they were not in SSA | |
37 | form, user variables appearing in ``value`` are to be regarded as | |
38 | part of the executable code space, whereas those in ``var`` are to | |
39 | be regarded as part of the source code space. There is no way to | |
40 | refer to the value bound to a user variable within a ``value`` | |
41 | expression. | |
42 | ||
43 | If ``value`` is ``GIMPLE_DEBUG_BIND_NOVALUE``, debug information | |
44 | generation machinery is informed that the variable ``var`` is | |
45 | unbound, i.e., that its value is indeterminate, which sometimes means | |
46 | it is really unavailable, and other times that the compiler could not | |
47 | keep track of it. | |
48 | ||
49 | Block and location information for the newly-created stmt are | |
50 | taken from ``stmt``, if given. | |
51 | ||
52 | .. function:: tree gimple_debug_bind_get_var (gimple stmt) | |
53 | ||
54 | Return the user variable :samp:`{var}` that is bound at ``stmt``. | |
55 | ||
56 | .. function:: tree gimple_debug_bind_get_value (gimple stmt) | |
57 | ||
58 | Return the value expression that is bound to a user variable at | |
59 | ``stmt``. | |
60 | ||
61 | .. function:: tree * gimple_debug_bind_get_value_ptr (gimple stmt) | |
62 | ||
63 | Return a pointer to the value expression that is bound to a user | |
64 | variable at ``stmt``. | |
65 | ||
66 | .. function:: void gimple_debug_bind_set_var (gimple stmt, tree var) | |
67 | ||
68 | Modify the user variable bound at ``stmt`` to :samp:`{var}`. | |
69 | ||
70 | .. function:: void gimple_debug_bind_set_value (gimple stmt, tree var) | |
71 | ||
72 | Modify the value bound to the user variable bound at ``stmt`` to | |
73 | :samp:`{value}`. | |
74 | ||
75 | .. function:: void gimple_debug_bind_reset_value (gimple stmt) | |
76 | ||
77 | Modify the value bound to the user variable bound at ``stmt`` so | |
78 | that the variable becomes unbound. | |
79 | ||
80 | .. function:: bool gimple_debug_bind_has_value_p (gimple stmt) | |
81 | ||
82 | Return ``TRUE`` if ``stmt`` binds a user variable to a value, | |
83 | and ``FALSE`` if it unbinds the variable. | |
84 | ||
85 | .. function:: gimple gimple_build_debug_begin_stmt (tree block, location_t location) | |
86 | ||
87 | Build a ``GIMPLE_DEBUG`` statement with | |
88 | ``GIMPLE_DEBUG_BEGIN_STMT`` ``subcode``. The effect of this | |
89 | statement is to tell debug information generation machinery that the | |
90 | user statement at the given ``location`` and ``block`` starts at | |
91 | the point at which the statement is inserted. The intent is that side | |
92 | effects (e.g. variable bindings) of all prior user statements are | |
93 | observable, and that none of the side effects of subsequent user | |
94 | statements are. | |
95 | ||
96 | .. function:: gimple gimple_build_debug_inline_entry (tree block, location_t location) | |
97 | ||
98 | Build a ``GIMPLE_DEBUG`` statement with | |
99 | ``GIMPLE_DEBUG_INLINE_ENTRY`` ``subcode``. The effect of this | |
100 | statement is to tell debug information generation machinery that a | |
101 | function call at ``location`` underwent inline substitution, that | |
102 | ``block`` is the enclosing lexical block created for the | |
103 | substitution, and that at the point of the program in which the stmt is | |
104 | inserted, all parameters for the inlined function are bound to the | |
105 | respective arguments, and none of the side effects of its stmts are | |
3ed1b4ce | 106 | observable. |