Hi Pierre-Marie,

> >From f8cb12e93bc4b317bf03dd31fc158cc05fc60367 Mon Sep 17 00:00:00 2001
> From: Pierre-Marie de Rodat <derodat@adacore.com>
> Date: Thu, 5 Feb 2015 17:00:06 +0100
> Subject: [PATCH] DWARF: handle non-local references in nested functions
> 
> GDB's current behavior when dealing with non-local references in the
> context of nested fuctions is approximative:
> 
>   - code using valops.c:value_of_variable read the first available stack
>     frame that holds the corresponding variable (whereas there can be
>     multiple candidates for this);
> 
>   - code directly relying on read_var_value will instead read non-local
>     variables in frames where they are not even defined.
> 
> This change adds the necessary context to symbol reads (to get the block
> they belong to) and to blocks (the static link property, if any) so that
> GDB can make the proper decisions when dealing with non-local varibale
> references.
> 
> gdb/ChangeLog:
> 
> 	* ada-lang.c (ada_read_var_value): Add a var_block argument
> 	and pass it to default_read_var_value.
> 	* block.c (block_static_link): New accessor.
> 	* block.h (block_static_link): Declare it.
> 	* buildsym.c (finish_block_internal): Add a static_link
>       [...]

This patch is causing a crash on some platforms, as explained by
the revision log of the attached patch.

gdb/ChangeLog:

        * dwarf2loc.c (locexpr_get_frame_base): Renames
        block_op_get_frame_base.
        (dwarf2_block_frame_base_locexpr_funcs): Replace reference to
        block_op_get_frame_base by reference to locexpr_get_frame_base.
        (loclist_get_frame_base): New function, near identical copy of
        locexpr_get_frame_base.
        (dwarf2_block_frame_base_loclist_funcs): Replace reference to
        block_op_get_frame_base by reference to loclist_get_frame_base.

Tested on x86_64-darwin (AdaCore testsuite), and x86_64-linux
(official testsuite).

As also mentioned in the revision log of the patch, we can probably
do some refactoring, or perhaps a different API in the vector that
just extracts the needed data (per_cu, at the moment) from symbol's
SYMBOL_LOCATION_BATON. Then, instead of calling the method to get
the function frame_base, you have a function that gets it by using
that different symbol_block_ops function.

But, I'd suggest fixing the issue the obvious way first, and doing
the cleanup that as a follow up. I wanted to help with the cleanup,
but I am not going to be available for a while, so here goes...

Thanks!
-- 
Joel