GDB (API)
/home/stan/gdb/src/gdb/prologue-value.h
Go to the documentation of this file.
00001 /* Interface to prologue value handling for GDB.
00002    Copyright (C) 2003-2013 Free Software Foundation, Inc.
00003 
00004    This file is part of GDB.
00005 
00006    This program is free software; you can redistribute it and/or modify
00007    it under the terms of the GNU General Public License as published by
00008    the Free Software Foundation; either version 3 of the License, or
00009    (at your option) any later version.
00010 
00011    This program is distributed in the hope that it will be useful,
00012    but WITHOUT ANY WARRANTY; without even the implied warranty of
00013    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
00014    GNU General Public License for more details.
00015 
00016    You should have received a copy of the GNU General Public License
00017    along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
00018 
00019 #ifndef PROLOGUE_VALUE_H
00020 #define PROLOGUE_VALUE_H
00021 
00022 /* When we analyze a prologue, we're really doing 'abstract
00023    interpretation' or 'pseudo-evaluation': running the function's code
00024    in simulation, but using conservative approximations of the values
00025    it would have when it actually runs.  For example, if our function
00026    starts with the instruction:
00027 
00028       addi r1, 42     # add 42 to r1
00029 
00030    we don't know exactly what value will be in r1 after executing this
00031    instruction, but we do know it'll be 42 greater than its original
00032    value.
00033 
00034    If we then see an instruction like:
00035 
00036       addi r1, 22     # add 22 to r1
00037 
00038    we still don't know what r1's value is, but again, we can say it is
00039    now 64 greater than its original value.
00040 
00041    If the next instruction were:
00042 
00043       mov r2, r1      # set r2 to r1's value
00044 
00045    then we can say that r2's value is now the original value of r1
00046    plus 64.
00047 
00048    It's common for prologues to save registers on the stack, so we'll
00049    need to track the values of stack frame slots, as well as the
00050    registers.  So after an instruction like this:
00051 
00052       mov (fp+4), r2
00053 
00054    then we'd know that the stack slot four bytes above the frame
00055    pointer holds the original value of r1 plus 64.
00056 
00057    And so on.
00058 
00059    Of course, this can only go so far before it gets unreasonable.  If
00060    we wanted to be able to say anything about the value of r1 after
00061    the instruction:
00062 
00063       xor r1, r3      # exclusive-or r1 and r3, place result in r1
00064 
00065    then things would get pretty complex.  But remember, we're just
00066    doing a conservative approximation; if exclusive-or instructions
00067    aren't relevant to prologues, we can just say r1's value is now
00068    'unknown'.  We can ignore things that are too complex, if that loss
00069    of information is acceptable for our application.
00070 
00071    So when I say "conservative approximation" here, what I mean is an
00072    approximation that is either accurate, or marked "unknown", but
00073    never inaccurate.
00074 
00075    Once you've reached the current PC, or an instruction that you
00076    don't know how to simulate, you stop.  Now you can examine the
00077    state of the registers and stack slots you've kept track of.
00078 
00079    - To see how large your stack frame is, just check the value of the
00080      stack pointer register; if it's the original value of the SP
00081      minus a constant, then that constant is the stack frame's size.
00082      If the SP's value has been marked as 'unknown', then that means
00083      the prologue has done something too complex for us to track, and
00084      we don't know the frame size.
00085 
00086    - To see where we've saved the previous frame's registers, we just
00087      search the values we've tracked --- stack slots, usually, but
00088      registers, too, if you want --- for something equal to the
00089      register's original value.  If the ABI suggests a standard place
00090      to save a given register, then we can check there first, but
00091      really, anything that will get us back the original value will
00092      probably work.
00093 
00094    Sure, this takes some work.  But prologue analyzers aren't
00095    quick-and-simple pattern patching to recognize a few fixed prologue
00096    forms any more; they're big, hairy functions.  Along with inferior
00097    function calls, prologue analysis accounts for a substantial
00098    portion of the time needed to stabilize a GDB port.  So I think
00099    it's worthwhile to look for an approach that will be easier to
00100    understand and maintain.  In the approach used here:
00101 
00102    - It's easier to see that the analyzer is correct: you just see
00103      whether the analyzer properly (albiet conservatively) simulates
00104      the effect of each instruction.
00105 
00106    - It's easier to extend the analyzer: you can add support for new
00107      instructions, and know that you haven't broken anything that
00108      wasn't already broken before.
00109 
00110    - It's orthogonal: to gather new information, you don't need to
00111      complicate the code for each instruction.  As long as your domain
00112      of conservative values is already detailed enough to tell you
00113      what you need, then all the existing instruction simulations are
00114      already gathering the right data for you.
00115 
00116    A 'struct prologue_value' is a conservative approximation of the
00117    real value the register or stack slot will have.  */
00118 
00119 struct prologue_value {
00120 
00121   /* What sort of value is this?  This determines the interpretation
00122      of subsequent fields.  */
00123   enum {
00124 
00125     /* We don't know anything about the value.  This is also used for
00126        values we could have kept track of, when doing so would have
00127        been too complex and we don't want to bother.  The bottom of
00128        our lattice.  */
00129     pvk_unknown,
00130 
00131     /* A known constant.  K is its value.  */
00132     pvk_constant,
00133 
00134     /* The value that register REG originally had *UPON ENTRY TO THE
00135        FUNCTION*, plus K.  If K is zero, this means, obviously, just
00136        the value REG had upon entry to the function.  REG is a GDB
00137        register number.  Before we start interpreting, we initialize
00138        every register R to { pvk_register, R, 0 }.  */
00139     pvk_register,
00140 
00141   } kind;
00142 
00143   /* The meanings of the following fields depend on 'kind'; see the
00144      comments for the specific 'kind' values.  */
00145   int reg;
00146   CORE_ADDR k;
00147 };
00148 
00149 typedef struct prologue_value pv_t;
00150 
00151 
00152 /* Return the unknown prologue value --- { pvk_unknown, ?, ? }.  */
00153 pv_t pv_unknown (void);
00154 
00155 /* Return the prologue value representing the constant K.  */
00156 pv_t pv_constant (CORE_ADDR k);
00157 
00158 /* Return the prologue value representing the original value of
00159    register REG, plus the constant K.  */
00160 pv_t pv_register (int reg, CORE_ADDR k);
00161 
00162 
00163 /* Return conservative approximations of the results of the following
00164    operations.  */
00165 pv_t pv_add (pv_t a, pv_t b);               /* a + b */
00166 pv_t pv_add_constant (pv_t v, CORE_ADDR k); /* a + k */
00167 pv_t pv_subtract (pv_t a, pv_t b);          /* a - b */
00168 pv_t pv_logical_and (pv_t a, pv_t b);       /* a & b */
00169 
00170 
00171 /* Return non-zero iff A and B are identical expressions.
00172 
00173    This is not the same as asking if the two values are equal; the
00174    result of such a comparison would have to be a pv_boolean, and
00175    asking whether two 'unknown' values were equal would give you
00176    pv_maybe.  Same for comparing, say, { pvk_register, R1, 0 } and {
00177    pvk_register, R2, 0}.
00178 
00179    Instead, this function asks whether the two representations are the
00180    same.  */
00181 int pv_is_identical (pv_t a, pv_t b);
00182 
00183 
00184 /* Return non-zero if A is known to be a constant.  */
00185 int pv_is_constant (pv_t a);
00186 
00187 /* Return non-zero if A is the original value of register number R
00188    plus some constant, zero otherwise.  */
00189 int pv_is_register (pv_t a, int r);
00190 
00191 
00192 /* Return non-zero if A is the original value of register R plus the
00193    constant K.  */
00194 int pv_is_register_k (pv_t a, int r, CORE_ADDR k);
00195 
00196 /* A conservative boolean type, including "maybe", when we can't
00197    figure out whether something is true or not.  */
00198 enum pv_boolean {
00199   pv_maybe,
00200   pv_definite_yes,
00201   pv_definite_no,
00202 };
00203 
00204 
00205 /* Decide whether a reference to SIZE bytes at ADDR refers exactly to
00206    an element of an array.  The array starts at ARRAY_ADDR, and has
00207    ARRAY_LEN values of ELT_SIZE bytes each.  If ADDR definitely does
00208    refer to an array element, set *I to the index of the referenced
00209    element in the array, and return pv_definite_yes.  If it definitely
00210    doesn't, return pv_definite_no.  If we can't tell, return pv_maybe.
00211 
00212    If the reference does touch the array, but doesn't fall exactly on
00213    an element boundary, or doesn't refer to the whole element, return
00214    pv_maybe.  */
00215 enum pv_boolean pv_is_array_ref (pv_t addr, CORE_ADDR size,
00216                                  pv_t array_addr, CORE_ADDR array_len,
00217                                  CORE_ADDR elt_size,
00218                                  int *i);
00219 
00220 
00221 /* A 'struct pv_area' keeps track of values stored in a particular
00222    region of memory.  */
00223 struct pv_area;
00224 
00225 /* Create a new area, tracking stores relative to the original value
00226    of BASE_REG.  If BASE_REG is SP, then this effectively records the
00227    contents of the stack frame: the original value of the SP is the
00228    frame's CFA, or some constant offset from it.
00229 
00230    Stores to constant addresses, unknown addresses, or to addresses
00231    relative to registers other than BASE_REG will trash this area; see
00232    pv_area_store_would_trash.
00233 
00234    To check whether a pointer refers to this area, only the low
00235    ADDR_BIT bits will be compared.  */
00236 struct pv_area *make_pv_area (int base_reg, int addr_bit);
00237 
00238 /* Free AREA.  */
00239 void free_pv_area (struct pv_area *area);
00240 
00241 
00242 /* Register a cleanup to free AREA.  */
00243 struct cleanup *make_cleanup_free_pv_area (struct pv_area *area);
00244 
00245 
00246 /* Store the SIZE-byte value VALUE at ADDR in AREA.
00247 
00248    If ADDR is not relative to the same base register we used in
00249    creating AREA, then we can't tell which values here the stored
00250    value might overlap, and we'll have to mark everything as
00251    unknown.  */
00252 void pv_area_store (struct pv_area *area,
00253                     pv_t addr,
00254                     CORE_ADDR size,
00255                     pv_t value);
00256 
00257 /* Return the SIZE-byte value at ADDR in AREA.  This may return
00258    pv_unknown ().  */
00259 pv_t pv_area_fetch (struct pv_area *area, pv_t addr, CORE_ADDR size);
00260 
00261 /* Return true if storing to address ADDR in AREA would force us to
00262    mark the contents of the entire area as unknown.  This could happen
00263    if, say, ADDR is unknown, since we could be storing anywhere.  Or,
00264    it could happen if ADDR is relative to a different register than
00265    the other stores base register, since we don't know the relative
00266    values of the two registers.
00267 
00268    If you've reached such a store, it may be better to simply stop the
00269    prologue analysis, and return the information you've gathered,
00270    instead of losing all that information, most of which is probably
00271    okay.  */
00272 int pv_area_store_would_trash (struct pv_area *area, pv_t addr);
00273 
00274 
00275 /* Search AREA for the original value of REGISTER.  If we can't find
00276    it, return zero; if we can find it, return a non-zero value, and if
00277    OFFSET_P is non-zero, set *OFFSET_P to the register's offset within
00278    AREA.  GDBARCH is the architecture of which REGISTER is a member.
00279 
00280    In the worst case, this takes time proportional to the number of
00281    items stored in AREA.  If you plan to gather a lot of information
00282    about registers saved in AREA, consider calling pv_area_scan
00283    instead, and collecting all your information in one pass.  */
00284 int pv_area_find_reg (struct pv_area *area,
00285                       struct gdbarch *gdbarch,
00286                       int reg,
00287                       CORE_ADDR *offset_p);
00288 
00289 
00290 /* For every part of AREA whose value we know, apply FUNC to CLOSURE,
00291    the value's address, its size, and the value itself.  */
00292 void pv_area_scan (struct pv_area *area,
00293                    void (*func) (void *closure,
00294                                  pv_t addr,
00295                                  CORE_ADDR size,
00296                                  pv_t value),
00297                    void *closure);
00298 
00299 
00300 #endif /* PROLOGUE_VALUE_H */
 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Defines