Re: RFC: tracepoints: abstract frame base finding in dwarf2loc.c

[Jim Blandy <jimb@codesourcery.com>]

"Ulrich Weigand" <uweigand at de.ibm.com> writes:
> Jim Blandy wrote:
>
>> Here's a change to dwarf2loc.c that pulls out the guts of the code to
>> find a function symbol's frame base expression into its own function.
>> We'll also use this function to find frame bases for variables we're
>> collecting at a tracepoint, in a later patch.  There should be no
>> change in behavior.  Tested on i386 Linux with no regressions.
>
> Nice; I assume you'll be using that to handle DW_OP_fbreg properly and
> get rid of the gdbarch_virtual_frame_pointer call in tracepoint_var_ref?

Yes, exactly!

>> +/* Find the frame base expression for PC, within FUNCTION.
>> +   Set *START to a pointer to it; set *LENGTH to its length.  */
>> +static void
>> +symbol_frame_base (struct symbol *function, CORE_ADDR pc,
>> +                   gdb_byte **start, size_t *length)
>
> I think the FUNCTION is redundant here, it can be recovered
> via find_pc_function (pc).  This should in all cases have the
> same result as the get_frame_function (frame) call below.
>
>> +  struct symbol *framefunc = get_frame_function (frame);
>> +  CORE_ADDR pc = get_frame_address_in_block (frame);

Yes, I think you're right.  I had been confused about whether the
pc-decrementing magic necessary for find_pc_function to get the right
answer would always happen correctly, but:
- in the dwarf_expr_frame_base case, the PC we'd supply comes from
  get_frame_address_in_block, which does the magic, and
- in the tracepoint case, the address is supplied directly by the
  user, so the magic isn't required.

Thanks!