Re: [patch] [VLA 2/2] Interpret FIELD_LOC_KIND_DWARF_BLOCK fields

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Jan Kratochvil wrote:

> check_typedef() will contain a memory leak with this patch.  This has been
> fixed by Tom Tromey's + mine <type> garbage collector to be posted later from:
> http://sourceware.org/gdb/wiki/ArcherBranchManagement
> archer-jankratochvil-type-refcount

If this is a pre-req, I think we should get that in the tree first ...

> +/* Evaluate DWARF expression at DATA ... DATA + SIZE with its result readable
> +   by dwarf_expr_fetch (RETVAL, 0).  FRAME parameter can be left NULL to call
> +   get_selected_frame to get its value.  Freeing of returned dwarf_expr_context
> +   is remembered on the current cleanup chain.  */
> +
> +static struct dwarf_expr_context *
> +dwarf_expr_prep_ctx (struct frame_info *frame, gdb_byte *data,
> +		     unsigned short size, struct dwarf2_per_cu_data *per_cu)
> +{
> +  struct dwarf_expr_context *ctx;
> +  struct dwarf_expr_baton baton;
> +
> +  if (!frame)
> +    frame = get_selected_frame (NULL);

I don't particularly like this.  We've been trying to get away from
having low-level routines depend on "global" setting like the currently
selected frame ...

Why is it correct to always evaluate VLA sizes relative to the currently
selected frame?  We might need to use some other frame, e.g. when re-
evaluating watchpoint expressions due to a shared-library event ...

It appears the need for using global data stems from the design decision
to have VLA sizes implicitly evaluated during the check_typedef call.
I'm wondering whether it wouldn't be better to use some other interface
to get at the current length of a VLA type, explicitly relative to a
specified frame (and possibly a specified data object).

B.t.w. this might also address the memory-management problem by not
having to allocate new types in the first place.

> --- gdb-cvs-dwarf2_get_attr_constant_value/gdb/dwarf2loc.h	2009-01-11 17:09:14.000000000 +0100
> +++ gdb-cvs-dwarf_block-eval/gdb/dwarf2loc.h	2009-01-12 10:37:22.000000000 +0100
> @@ -72,4 +72,7 @@ struct dwarf2_loclist_baton
>  extern const struct symbol_ops dwarf2_locexpr_funcs;
>  extern const struct symbol_ops dwarf2_loclist_funcs;
>  
> +extern CORE_ADDR dwarf_locexpr_baton_eval
> +  (struct dwarf2_locexpr_baton *dlbaton);

Making this dwarf2-specific function directly callable seems to break
the abstraction layer that "hides" specific details of any particular
debug info formati from common code.

However, I'm not sure I see a clean solution for this.  Ideally, we'd
have something like a LOC_COMPUTED with callback functions, to handle
format-specific field_loc_kind values.  But that would require adding
a new pointer to "struct field", which I don't really like either as
this is a quite space-critical data structure ...

I guess we can live for now with the broken abstraction, unless someone
has some better idea.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com