Re: [WIP]: LOC_COMPUTED and LOC_COMPUTED_ARG

[Daniel Berlin <dan@dberlin.org>]

On Sat, 6 Apr 2002, Andrew Cagney wrote:

> > + 	case DW_OP_fbreg:
> > + 	  {
> > + 	    struct symbol *framefunc;
> > + 	    unsigned char *datastart;
> > + 	    unsigned char *dataend;
> > + 	    struct dwarf_block *theblock;
> > + 	    struct locexpr_baton *baton;
> > + 
> > + 	    framefunc = get_frame_function (frame);
> > + 	    op_ptr = read_sleb128 (op_ptr, &offset);
> > + 	    baton = SYMBOL_LOCATION_BATON (framefunc);
> > + 	    theblock = &baton->locexpr;
> > + 	    datastart = theblock->data;
> > + 	    dataend = theblock->data + theblock->size;
> > + 	    result = execute_stack_op (var, datastart, dataend, frame, 0, NULL) + offset;
> > + 	  }
> > + 	  break;
> 
> and
> 
> > - the frame base address (for DW_OP_fbreg)
> > 
> > 
> > Not possible.
> > the frame base can be a location list.
> > That's why it pulls it out of the frame function on the fly. 
> 
> Something I've never understood.  Shouldn't frame_base be stored in 
> frame->base as part of the initial frame creation.  Hence avoiding this 
> recursion?

Theoretically you could, but it's sort of pointless.
You still end up doing the same lookup.
It also hides the code, since the code to create frames is nowhere 
near the dwarf2 reader.

It makes it look like "magic" to someone looking at the evaluator.
> 
> Andrew
> 
>