This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 01/12] type: add c99 variable length array support
- From: Joel Brobecker <brobecker at adacore dot com>
- To: gdb-patches at sourceware dot org
- Cc: Sanimir Agovic <sanimir dot agovic at intel dot com>
- Date: Fri, 18 Apr 2014 12:06:23 -0700
- Subject: Re: [PATCH 01/12] type: add c99 variable length array support
- Authentication-results: sourceware.org; auth=none
- References: <0377C58828D86C4588AEEC42FC3B85A71D8507B7 at IRSMSX105 dot ger dot corp dot intel dot com> <1397495596-25364-1-git-send-email-brobecker at adacore dot com> <1397495596-25364-2-git-send-email-brobecker at adacore dot com>
Hi Sanimir, (and dwarf2* experts!)
Just looking through the code again, I found:
> +/* Evaluates a dwarf expression and stores the result in VAL, expecting
> + that the dwarf expression only produces a single CORE_ADDR. ADDR is a
> + context (location of a variable) and might be needed to evaluate the
> + location expression.
> + Returns 1 on success, 0 otherwise. */
> +
> +static int
> +dwarf2_locexpr_baton_eval (const struct dwarf2_locexpr_baton *dlbaton,
> + CORE_ADDR addr, CORE_ADDR *valp)
The "addr" parameter is unused in this case, and I am hoping that
this would be normal. Re-reading location expressions, I don't see
a lot of cases that could happen, and none of them see to require
an address to start with). What do you think?
The reason why I ended up looking at this code is because the current
interface for resolving bounds needs an address. When you work from
a value, there could be no address (Eg. if the value is inside a
register, or its an lval_computed value). Currently, the interface
works works with types (resolve_dynamic_type(type+addr)), but it
would also be convenient to have a resolve_dynamic_value(value).
If we can remove that address, then a number of simplifications
can be made. I'll take care of all required updates, but I was
wondering what your thoughts on this were...
Thanks!
> +{
> + struct dwarf_expr_context *ctx;
> + struct dwarf_expr_baton baton;
> + struct objfile *objfile;
> + struct cleanup *cleanup;
> +
> + if (dlbaton == NULL || dlbaton->size == 0)
> + return 0;
> +
> + ctx = new_dwarf_expr_context ();
> + cleanup = make_cleanup_free_dwarf_expr_context (ctx);
> +
> + baton.frame = get_selected_frame (NULL);
> + baton.per_cu = dlbaton->per_cu;
> +
> + objfile = dwarf2_per_cu_objfile (dlbaton->per_cu);
> +
> + ctx->gdbarch = get_objfile_arch (objfile);
> + ctx->addr_size = dwarf2_per_cu_addr_size (dlbaton->per_cu);
> + ctx->ref_addr_size = dwarf2_per_cu_ref_addr_size (dlbaton->per_cu);
> + ctx->offset = dwarf2_per_cu_text_offset (dlbaton->per_cu);
> + ctx->funcs = &dwarf_expr_ctx_funcs;
> + ctx->baton = &baton;
> +
> + dwarf_expr_eval (ctx, dlbaton->data, dlbaton->size);
> +
> + switch (ctx->location)
> + {
> + case DWARF_VALUE_REGISTER:
> + case DWARF_VALUE_MEMORY:
> + case DWARF_VALUE_STACK:
> + *valp = dwarf_expr_fetch_address (ctx, 0);
> + if (ctx->location == DWARF_VALUE_REGISTER)
> + *valp = dwarf_expr_read_addr_from_reg (&baton, *valp);
> + do_cleanups (cleanup);
> + return 1;
> + case DWARF_VALUE_LITERAL:
> + *valp = extract_signed_integer (ctx->data, ctx->len,
> + gdbarch_byte_order (ctx->gdbarch));
> + do_cleanups (cleanup);
> + return 1;
> + /* Unsupported dwarf values. */
> + case DWARF_VALUE_OPTIMIZED_OUT:
> + case DWARF_VALUE_IMPLICIT_POINTER:
> + break;
> + }
> +
> + do_cleanups (cleanup);
> + return 0;
--
Joel