This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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);
     }

So perhaps it would be better to fix this by allowing the user to
specify the context directly, like when printing a variable of type
foo instead of just the type foo:

  (gdb) ptype 'char.c'::afoo
  type = char
  (gdb) ptype 'int.c'::afoo
  type = int
  (gdb) ptype 'main.c'::afoo
  type = long int

So something like the following, which currently produces an error:

  (gdb) ptype 'main.c'::foo
  Cannot look up value of a typedef

-Fred


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]