This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] better dwarf checking for values on the stack


On Tue, Sep 15, 2009 at 1:20 PM, Cary Coutant <ccoutant@google.com> wrote:
>> ? ? ? ?* dwarf2expr.c (dwarf_expr_grow_stack): Update calculation of
>> ? ? ? ?size of stack value.
>> ? ? ? ?(dwarf_expr_push): New arg in_stack_memory, all callers updated.
>> ? ? ? ?(dwarf_expr_fetch_in_stack_memory): New function.
>> ? ? ? ?(add_piece): Set in_stack_memory for non-literal values.
>> ? ? ? ?(execute_stack_op): Allow ops to specify where the value is on the
>> ? ? ? ?program's stack.
>> ? ? ? ?(execute_stack_op, case DW_OP_fbreg): Mark value as in stack memory.
>> ? ? ? ?(execute_stack_op, case DW_OP_call_frame_cfa): Ditto.
>> ? ? ? ?(execute_stack_op, case DW_OP_dup): Copy in_stack_memory flag.
>> ? ? ? ?(execute_stack_op, cases DW_OP_pick, DW_OP_over): Ditto.
>> ? ? ? ?(execute_stack_op, cases DW_OP_swap, DW_OP_rot): Update type of
>> ? ? ? ?dwarf stack value.
>
> It seems to me that if you're going to go this route (rather than the
> heuristic approach of your first patch), you need to do some type
> algebra here. You've got three types of things on the expression
> stack; let's call them M (generic addresses, probably not on the
> memory stack), S (addresses of things on the memory stack), and K
> (unitless constants). There are combining rules for these types; for
> example:
>
> ?K <anyop> K -> K
> ?M +/- K -> M
> ?K +/- M -> M
> ?M - M -> K
> ?S +/- K -> S
> ?K +/- S -> S
> ?S - S -> K
>
> There are combinations that don't make sense, but aren't technically
> illegal in the DWARF spec, so these will need to be handled
> conservatively; for example:
>
> ?M + M -> M
> ?M * M -> M
> ?M + S -> M
>
> You could have an expression like S - S + M [ = (S - S) + M = K + M ->
> M ] -- admittedly unlikely, but the same can be said for Tom's example
> that fooled the heuristic approach -- which should yield a memory
> address, but from what I can tell will end up claiming it's a stack
> address.

Yeah, if we wanted to catch more cases of what's on the stack than
what's currently there does, then we need to appropriately handle the
math.  I explicitly left that for another day.

dwarf2expr.c:

      /* Assume the value is not in stack memory.
         Code that knows otherwise sets this to 1.
         Some arithmetic on stack addresses can probably be assumed to
still
         be a stack address, but we skip this complication for now.
         This is just an optimization, so it's always ok to punt
         and leave this as 0.  */
      int in_stack_memory = 0;

Sound ok?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]