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

[Daniel Jacobowitz <drow@false.org>]

On Mon, Jan 23, 2006 at 10:27:05AM -0500, Fred Fish wrote:
> On Sunday 15 January 2006 23:22, Jim Blandy wrote:
> > On 1/15/06, Daniel Jacobowitz <drow@false.org> wrote:
> > > Given the followups, I think this patch is OK.  Jim, do you agree?
> > 
> > I think we're going to end up coming back to it, but the patch is
> > definitely an improvement over the status quo, and doesn't interfere
> > with further improvements, so I think the patch is okay too.
> 
> The patch doesn't work though if there is a current frame, from
> debugging a running process or examining a core file.  This is because
> of the order for searching for the block:
> 
>    if (!block)
>      block = get_selected_block (&expression_context_pc);
>  
>    if (!block)
>      {
>        struct symtab_and_line cursal = get_current_source_symtab_and_line ();
>        if (cursal.symtab)
>        block = BLOCKVECTOR_BLOCK (BLOCKVECTOR (cursal.symtab), STATIC_BLOCK);
>      }

I don't understand.  What doesn't work?  Is it something that works
without the patch, or not?  I don't understand how your examples relate
to your description of the problem anymore.

If we're going to continue discussing this issue for much longer, I may
ask you to disable the test case.

> So something like the following, which currently produces an error:
> 
>   (gdb) ptype 'main.c'::foo
>   Cannot look up value of a typedef

Well that seems like a reasonable thing to fix anyway; ptype (and
sizeof!) should be using a non-side-effects evaluation anyway.

-- 
Daniel Jacobowitz
CodeSourcery