This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Fix ptype problem printing typedefs defined differently in different compilation units
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.