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: [PATCH 01/12] type: add c99 variable length array support


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


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