Re: [PATCH] Fix ptype problem printing typedefs defined differently in different compilation units

[Jim Blandy <jimb@red-bean.com>]

On 1/3/06, Fred Fish <fnf@specifix.com> wrote:
> > I have some questions about the patch, though.
> > get_current_source_symtab_and_line is a user-interface thing, and I'm
> > uncomfortable calling it from one of our fundamental lookup functions.
>
> There is a static pointer to the current source symtab in source.c,
> and only functions in that file have direct access to it.  All the
> rest of gdb seems to use one of the accessor functions exported from
> source.c:
>
>         get_current_source_symtab_and_line
>         set_current_source_symtab_and_line
>         clear_current_source_symtab_and_line

I wasn't making an argument from the layout of GDB's source code. 
Conceptually, the current source file and line are properties of the
user interface --- of a command-line user interface, really.  The
fundamantal lookup code ought to be independent of that, it seems to
me.

> > Why isn't the right block being passed to lookup_symbol in the first
> > place?
> ...
> parse_exp_in_context() sees that block is zero and tries to find
> expression_context_block by calling get_selected_block(), but since
> the target isn't running, that returns zero, which gets saved in
> expression_context_block.

What would break if get_selected_block used, in the absence of a
frame, the current source position?  Or, if get_selected_block really
needs to return zero when there's no stack, what would break if
parse_exp_in_context used the current source position as a fallback
when get_selected_block returns zero?  It seems reasonable to me.