This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [WIP]: LOC_COMPUTED and LOC_COMPUTED_ARG
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: Daniel Berlin <dan at dberlin dot org>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sat, 06 Apr 2002 19:34:32 -0500
- Subject: Re: [WIP]: LOC_COMPUTED and LOC_COMPUTED_ARG
- References: <Pine.LNX.4.44.0203261057000.9844-100000@dberlin.org>
> + 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?
Andrew