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

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

[Fred Fish]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]

When examining an executable (but not running it) if you have a
typedef in two different compilation units, with the same name but
different types, the ptype command will print the type for the first
one it finds in a scan of all the loaded symtabs, regardless of any
source context you may have selected.

Of course the wisdom of having writing this sort of code in the first
place is somewhat suspect...  :-)

Attached is a patch that adds a test to the ptype.exp test for this
case, by alternately listing functions from different compilation
units (thus setting gdb's idea of the current source context) and
verifying that ptype prints the type correctly based on the context.

The patch also adds a proposed fix for the problem, which is to look
in the current source symtab for the name, before scanning all the
symtabs.

-Fred




[-- Attachment #2: symtab.patch2 --]
[-- Type: text/x-diff, Size: 7183 bytes --]

Gdb ChangeLog entry:

 2006-01-03  Fred Fish  <fnf@specifix.com>
 
 	* symtab.c (lookup_symbol_aux_symtab): Add declaration and
 	definition of function to look up name in a specific symtab.
 	(lookup_symbol_aux): Add cursal variable and code to set it.
 	Call lookup_symbol_aux_symtab with current source symtab.
 	
Gdb testsuite ChangeLog entry:

 2006-01-03  Fred Fish  <fnf@specifix.com>

	* gdb.base/ptype.c (foo): Add typedef.
	(intfoo): Add function.
	* gdb.base/ptype1.c: New file.
	* gdb.base/ptype.exp: Handle compilation and linking with two
	source files.  Test that proper type for "foo" is found based
	on source context rather than first match found in symtabs.

Index: symtab.c
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/symtab.c,v
retrieving revision 1.1.1.2
diff -c -p -r1.1.1.2 symtab.c
*** symtab.c	30 Dec 2005 18:53:03 -0000	1.1.1.2
--- symtab.c	3 Jan 2006 18:04:01 -0000
*************** struct symbol *lookup_symbol_aux_local (
*** 94,99 ****
--- 94,107 ----
  					struct symtab **symtab);
  
  static
+ struct symbol *lookup_symbol_aux_symtab (struct symtab *s,
+ 					 int block_index,
+ 					 const char *name,
+ 					 const char *linkage_name,
+ 					 const domain_enum domain,
+ 					 struct symtab **symtab);
+ 
+ static
  struct symbol *lookup_symbol_aux_symtabs (int block_index,
  					  const char *name,
  					  const char *linkage_name,
*************** lookup_symbol_aux (const char *name, con
*** 1079,1084 ****
--- 1087,1093 ----
  		   int *is_a_field_of_this, struct symtab **symtab)
  {
    struct symbol *sym;
+   struct symtab_and_line cursal;
  
    /* Make sure we do something sensible with is_a_field_of_this, since
       the callers that set this parameter to some non-null value will
*************** lookup_symbol_aux (const char *name, con
*** 1122,1127 ****
--- 1131,1144 ----
    if (sym != NULL)
      return sym;
  
+   /* Check the symtab associated with the current source line. */
+ 
+   cursal = get_current_source_symtab_and_line ();
+   sym = lookup_symbol_aux_symtab (cursal.symtab, STATIC_BLOCK, name,
+ 				  linkage_name, domain, symtab);
+   if (sym != NULL)
+     return sym;
+ 
    /* Now search all static file-level symbols.  Not strictly correct,
       but more useful than an error.  Do the symtabs first, then check
       the psymtabs.  If a psymtab indicates the existence of the
*************** lookup_symbol_aux_block (const char *nam
*** 1215,1220 ****
--- 1232,1269 ----
    return NULL;
  }
  
+ /* Check to see if the symbol is defined in a specific symtab.
+    BLOCK_INDEX should be either GLOBAL_BLOCK or STATIC_BLOCK,
+    depending on whether or not we want to search global symbols or
+    static symbols.  */
+ 
+ static struct symbol *
+ lookup_symbol_aux_symtab (struct symtab *s, int block_index,
+ 			  const char *name, const char *linkage_name,
+ 			  const domain_enum domain,
+ 			  struct symtab **symtab)
+ {
+   struct symbol *sym;
+   struct blockvector *bv;
+   const struct block *block;
+ 
+   if (s != NULL)
+     {
+       bv = BLOCKVECTOR (s);
+       block = BLOCKVECTOR_BLOCK (bv, block_index);
+       sym = lookup_block_symbol (block, name, linkage_name, domain);
+       if (sym)
+ 	{
+ 	  block_found = block;
+ 	  if (symtab != NULL)
+ 	    *symtab = s;
+ 	  return fixup_symbol_section (sym, s->objfile);
+ 	}
+     }
+ 
+   return NULL;
+ }
+ 
  /* Check to see if the symbol is defined in one of the symtabs.
     BLOCK_INDEX should be either GLOBAL_BLOCK or STATIC_BLOCK,
     depending on whether or not we want to search global symbols or
Index: testsuite/gdb.base/ptype.c
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/testsuite/gdb.base/ptype.c,v
retrieving revision 1.1.1.1
diff -c -p -r1.1.1.1 ptype.c
*** testsuite/gdb.base/ptype.c	8 Oct 2005 19:36:19 -0000	1.1.1.1
--- testsuite/gdb.base/ptype.c	3 Jan 2006 05:17:21 -0000
*************** func_type v_func_type;
*** 259,264 ****
--- 259,273 ----
  
  /***********/
  
+ typedef int foo;
+ 
+ foo intfoo (afoo)
+ {
+   return (afoo * 2);
+ }
+ 
+ /***********/
+ 
  int main ()
  {
    /* Ensure that malloc is a pointer type; avoid use of "void" and any include files. */
Index: testsuite/gdb.base/ptype.exp
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/testsuite/gdb.base/ptype.exp,v
retrieving revision 1.1.1.1
diff -c -p -r1.1.1.1 ptype.exp
*** testsuite/gdb.base/ptype.exp	8 Oct 2005 19:36:19 -0000	1.1.1.1
--- testsuite/gdb.base/ptype.exp	3 Jan 2006 05:29:40 -0000
*************** set prms_id 0
*** 31,39 ****
  set bug_id 0
  
  set testfile "ptype"
! set srcfile ${testfile}.c
  set binfile ${objdir}/${subdir}/${testfile}
! if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
       gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
  }
  
--- 31,47 ----
  set bug_id 0
  
  set testfile "ptype"
! set srcfile0 ${testfile}.c
! set srcfile1 ${testfile}1.c
  set binfile ${objdir}/${subdir}/${testfile}
! 
! if  { [gdb_compile "${srcdir}/${subdir}/${srcfile0}" "${binfile}0.o" object {debug}] != "" } {
!      gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
! }
! if  { [gdb_compile "${srcdir}/${subdir}/${srcfile1}" "${binfile}1.o" object {debug}] != "" } {
!      gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
! }
! if  { [gdb_compile "${binfile}0.o ${binfile}1.o" "${binfile}" executable {debug}] != "" } {
       gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
  }
  
*************** ptype_maybe_prototyped "ffptr" "int (*(*
*** 574,579 ****
--- 582,599 ----
  ptype_maybe_prototyped "fffptr" "int (*(*(*)(char))(short int))(long int)" \
                                  "int (*(*(*)())())()"
  
+ # Test printing type of typedefs in different scopes, with same name
+ # but different type.
+ 
+ gdb_test "list intfoo" ""
+ gdb_test "ptype foo" "type = int" "ptype foo typedef after first list of intfoo"
+ gdb_test "list charfoo" ""
+ gdb_test "ptype foo" "type = char" "ptype foo typedef after first list of charfoo"
+ gdb_test "list intfoo" ""
+ gdb_test "ptype foo" "type = int" "ptype foo typedef after second list of intfoo"
+ gdb_test "list charfoo" ""
+ gdb_test "ptype foo" "type = char" "ptype foo typedef after second list of charfoo"
+ 
  # Test printing type of string constants and array constants, but
  # requires a running process.  These call malloc, and can take a long
  # time to execute over a slow serial link, so increase the timeout.
Index: testsuite/gdb.base/ptype1.c
===================================================================
RCS file: testsuite/gdb.base/ptype1.c
diff -N testsuite/gdb.base/ptype1.c
*** /dev/null	1 Jan 1970 00:00:00 -0000
--- testsuite/gdb.base/ptype1.c	3 Jan 2006 05:31:00 -0000
***************
*** 0 ****
--- 1,6 ----
+ typedef char foo;
+ 
+ foo charfoo (afoo)
+ {
+   return (afoo * 2);
+ }

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

[Jim Blandy]

On 1/3/06, Fred Fish <fnf@specifix.com> wrote:
> The patch also adds a proposed fix for the problem, which is to look
> in the current source symtab for the name, before scanning all the
> symtabs.

The test looks good; please commit that.

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.
 Why isn't the right block being passed to lookup_symbol in the first
place?

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

[Fred Fish]

On Tuesday 03 January 2006 18:15, Jim Blandy wrote:
> The test looks good; please commit that.

OK.

> 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

> Why isn't the right block being passed to lookup_symbol in the first
> place?

ptype_command() calls parse_expression() with the name of the type as
the only argument

parse_expression() calls parse_exp_1() with zero as the block

parse_exp_1() simply calls parse_exp_in_context(), passing on zero.

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.

parse_exp_context() then calls the C parser, which calls the lexer, which
calls lookup_symbol() with the current value of expression_context_block,
which is zero.

-Fred

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

[Jim Blandy]

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.

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

[Fred Fish]

On Tuesday 03 January 2006 22:45, Jim Blandy wrote:

> 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.

Excellent questions.  Sounds like reasonable things to investigate for
alternative solutions.  I'll give it a try and see...

-Fred

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

[Fred Fish]

On Tuesday 03 January 2006 22:45, Jim Blandy wrote:

> 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.

That seems like the most reasonable alternative to me as well.  The
following patch solves the same problem as the original patch, in what
is probably a little cleaner way.  I don't get any testsuite
regressions when using it.

-Fred

2006-01-04  Fred Fish  <fnf@fishfood.ninemoons.com>

	* parse.c (source.h): Include.
	(parse_exp_in_context):  Use static source context if no
	other context found.

Index: parse.c
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/parse.c,v
retrieving revision 1.1.1.2
diff -c -p -r1.1.1.2 parse.c
*** parse.c	30 Dec 2005 18:53:04 -0000	1.1.1.2
--- parse.c	4 Jan 2006 18:35:57 -0000
***************
*** 52,57 ****
--- 52,58 ----
  #include "doublest.h"
  #include "gdb_assert.h"
  #include "block.h"
+ #include "source.h"
  
  /* Standard set of definitions for printing, dumping, prefixifying,
   * and evaluating expressions.  */
*************** parse_exp_in_context (char **stringptr, 
*** 1075,1087 ****
    old_chain = make_cleanup (free_funcalls, 0 /*ignore*/);
    funcall_chain = 0;
  
    if (block)
      {
        expression_context_block = block;
        expression_context_pc = BLOCK_START (block);
      }
-   else
-     expression_context_block = get_selected_block (&expression_context_pc);
  
    expout_size = 10;
    expout_ptr = 0;
--- 1076,1102 ----
    old_chain = make_cleanup (free_funcalls, 0 /*ignore*/);
    funcall_chain = 0;
  
+   /* If no context specified, try using the current frame, if any. */
+ 
+   if (!block)
+     block = get_selected_block (&expression_context_pc);
+ 
+   /* Fall back to using the current source static context, if any. */
+ 
+   if (!block)
+     {
+       struct symtab_and_line cursal = get_current_source_symtab_and_line ();
+       if (cursal.symtab)
+ 	block = BLOCKVECTOR_BLOCK (BLOCKVECTOR (cursal.symtab), STATIC_BLOCK);
+     }
+ 
+   /* Save the context, if specified by caller, or found above. */
+ 
    if (block)
      {
        expression_context_block = block;
        expression_context_pc = BLOCK_START (block);
      }
  
    expout_size = 10;
    expout_ptr = 0;

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

[Jim Blandy]

On 1/4/06, Fred Fish <fnf@specifix.com> wrote:
> 2006-01-04  Fred Fish  <fnf@fishfood.ninemoons.com>
>
>         * parse.c (source.h): Include.
>         (parse_exp_in_context):  Use static source context if no
>         other context found.

Thanks for revising this!

Would it be hard to find the innermost block that contains the current
line?  Say, a sal->pc->block mapping?  We could fall back to the
static block if some step failed.

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

[Jim Blandy]

On 1/4/06, Fred Fish <fnf@specifix.com> wrote:
> 2006-01-04  Fred Fish  <fnf@fishfood.ninemoons.com>
>
>         * parse.c (source.h): Include.
>         (parse_exp_in_context):  Use static source context if no
>         other context found.

Thanks for revising this!

Would it be hard to find the innermost block that contains the current
line?  Say, a sal->pc->block mapping?  We could fall back to the
static block if some step failed.

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

[Daniel Jacobowitz]

On Wed, Jan 04, 2006 at 04:26:28PM -0800, Jim Blandy wrote:
> On 1/4/06, Fred Fish <fnf@specifix.com> wrote:
> > 2006-01-04  Fred Fish  <fnf@fishfood.ninemoons.com>
> >
> >         * parse.c (source.h): Include.
> >         (parse_exp_in_context):  Use static source context if no
> >         other context found.
> 
> Thanks for revising this!
> 
> Would it be hard to find the innermost block that contains the current
> line?  Say, a sal->pc->block mapping?  We could fall back to the
> static block if some step failed.

I think it'd be pretty complicated.  The line may map to multiple
functions, et cetera et cetera.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Jim Blandy]

On 1/4/06, Daniel Jacobowitz <drow@false.org> wrote:
> I think it'd be pretty complicated.  The line may map to multiple
> functions, et cetera et cetera.

Sure, doing a perfect job isn't really practical given GDB's present
data structures.  But we could do as well as (say) "break FILE:LINE if
COND" does at determining the proper scope for evaluating COND.

Fred, to be clear, I don't want to discourage you by piling on
suggestions.  I see the patch as a bug fix as it stands.  "Would it be
hard..." was a genuine question.

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

[Daniel Jacobowitz]

On Wed, Jan 04, 2006 at 04:04:49PM -0500, Fred Fish wrote:
> On Tuesday 03 January 2006 22:45, Jim Blandy wrote:
> 
> > 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.
> 
> That seems like the most reasonable alternative to me as well.  The
> following patch solves the same problem as the original patch, in what
> is probably a little cleaner way.  I don't get any testsuite
> regressions when using it.
> 
> -Fred
> 
> 2006-01-04  Fred Fish  <fnf@fishfood.ninemoons.com>
> 
> 	* parse.c (source.h): Include.
> 	(parse_exp_in_context):  Use static source context if no
> 	other context found.

Given the followups, I think this patch is OK.  Jim, do you agree?

(Since we currently have new, failing tests...)

-- 
Daniel Jacobowitz
CodeSourcery

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

[Jim Blandy]

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.

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

[Fred Fish]

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

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

[Daniel Jacobowitz]

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

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

[Fred Fish]

On Monday 23 January 2006 11:12, Daniel Jacobowitz wrote:
> I don't understand.  What doesn't work?  Is it something that works
> without the patch, or not?

Doesn't work without the patch, as it uses the type for the first
symtab it happens to find that has a definition for that type.

> I don't understand how your examples relate
> to your description of the problem anymore.

OK, I've attached a typescript at the bottom of this mail showing how
it fails in the presence of a core and/or running executable.

> > 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.

I can look at this, though it may be a week or so.

-Fred

============================================================================

Here is a simple testcase

$ cat main.c
typedef long foo;
foo longfoo;

main ()
{
  extern charfoo (char);
  extern intfoo (int);
  int a = 5;

  a = intfoo (a);
  a = charfoo (a);
  printf ("a = %d (should be 20)\n", a);
  *(char *)0 = 0;
}

$ cat int.c
typedef int foo;

intfoo (foo a)
{
  return (2 * a);
}

$ cat char.c
typedef char foo;

charfoo (foo a)
{
  return (2 * a);
}

============================================================================

Build testcase on Fedora Core 4 and generate corefile

$ make
gcc -g  --save-temps   -c -o main.o main.c
main.c: In function ‘main’:
main.c:12: warning: incompatible implicit declaration of built-in function ‘printf’
gcc -g  --save-temps   -c -o char.o char.c
gcc -g  --save-temps   -c -o int.o int.c
gcc -o main main.o char.o int.o 

$ ./main
a = 20 (should be 20)
Segmentation fault (core dumped)
$ mv core.* core

============================================================================

Use gdb to examine just the executable file

$ ../gdb main
(gdb) list main
1	typedef long foo;
2	foo longfoo;
3	
4	main ()
5	{
6	  extern charfoo (char);
7	  extern intfoo (int);
8	  int a = 5;
9	
10	  a = intfoo (a);
(gdb) ptype foo
type = long int			<===== OK
(gdb) list charfoo
1	typedef char foo;
2	
3	charfoo (foo a)
4	{
5	  return (2 * a);
6	}
(gdb) ptype foo
type = char			<===== OK
(gdb) list intfoo
1	typedef int foo;
2	
3	intfoo (foo a)
4	{
5	  return (2 * a);
6	}
(gdb) ptype foo
type = int			<===== OK
(gdb) quit

============================================================================

Use gdb to examine the executable file and core file

$ ../gdb main core
#0  0x080483de in main () at main.c:13
13	  *(char *)0 = 0;
(gdb) list main
1	typedef long foo;
2	foo longfoo;
3	
4	main ()
5	{
6	  extern charfoo (char);
7	  extern intfoo (int);
8	  int a = 5;
9	
10	  a = intfoo (a);
(gdb) ptype foo
type = long int			<===== OK
(gdb) list charfoo
1	typedef char foo;
2	
3	charfoo (foo a)
4	{
5	  return (2 * a);
6	}
(gdb) ptype foo
type = long int			<===== Prints using frame context
(gdb) list intfoo
1	typedef int foo;
2	
3	intfoo (foo a)
4	{
5	  return (2 * a);
6	}
(gdb) ptype foo
type = long int			<===== Prints using frame context
(gdb) quit

============================================================================

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

[Jim Blandy]

Are you sure you're not misunderstanding your typescript?  When you
have a core file, you have a frame, so it's always using the frame
context.  I think that's the correct behavior.  When there is a frame,
the source position (as established by 'list' commands) generally
doesn't override the frame position when deciding scopes.  It's the
same for (say) printing static variables.

What behavior would be most easily understood and used is arguable,
but this is, as I understand it, GDB's intended behavior.

So I don't think there's a problem with your patch.

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

[Fred Fish]

On Monday 23 January 2006 14:17, Jim Blandy wrote:
> Are you sure you're not misunderstanding your typescript?  When you
> have a core file, you have a frame, so it's always using the frame
> context. I think that's the correct behavior.

Agreed.

The problem isn't that it shouldn't be using the frame context, the
issues are (1) it behaves differently when using and not using a core
file (2) there is no way to print the type in other contexts.  I.E. if
you are poking around in the sources with the print command and want
to print a type using the source context, you can't easily do that.

This is why I think the correct and complete solution is to allow the
user to directly specify the context.

> When there is a frame,
> the source position (as established by 'list' commands) generally
> doesn't override the frame position when deciding scopes.  It's the
> same for (say) printing static variables.

Yup, which is why you can print static variables using the 'file'::var
syntax.

> So I don't think there's a problem with your patch.

I guess we could still use that patch to fall back to using the source
context when there is no overriding frame context, while working on
allowing the user to directly specify the source context.

-Fred

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

[Jim Blandy]

On 1/23/06, Fred Fish <fnf@specifix.com> wrote:
> This is why I think the correct and complete solution is to allow the
> user to directly specify the context.

Sure.  That would entail extending the 'type_exp' non-terminal to have
a FILENAME COLONCOLON TYPE production.  Sounds like the right thing.

What's confusing me, though, is that you seemed to present that
possibility as an alternative to the patch previously posted.  It
looks to me like both changes make sense, and they seem independent of
each other.  Since we have the test case in there failing right now,
I'd like to get the previous patch in, and perhaps continue the
discussion about filename qualification in a separate thread.

[commit] Fix ptype problem printing typedefs defined differently in different compilation units

[Fred Fish]

On Monday 23 January 2006 14:17, Jim Blandy wrote:
> So I don't think there's a problem with your patch.

I've committed the patch.

-Fred

 2006-01-24  Fred Fish  <fnf@specifix.com>

	* parse.c (source.h): Include.
	(parse_exp_in_context):  Use static source context if no
	other context found.

Index: parse.c
===================================================================
RCS file: /cvs/src/src/gdb/parse.c,v
retrieving revision 1.51
diff -c -p -r1.51 parse.c
*** parse.c	17 Dec 2005 22:34:01 -0000	1.51
--- parse.c	24 Jan 2006 14:49:59 -0000
***************
*** 52,57 ****
--- 52,58 ----
  #include "doublest.h"
  #include "gdb_assert.h"
  #include "block.h"
+ #include "source.h"
  
  /* Standard set of definitions for printing, dumping, prefixifying,
   * and evaluating expressions.  */
*************** parse_exp_in_context (char **stringptr, 
*** 1075,1087 ****
    old_chain = make_cleanup (free_funcalls, 0 /*ignore*/);
    funcall_chain = 0;
  
    if (block)
      {
        expression_context_block = block;
        expression_context_pc = BLOCK_START (block);
      }
-   else
-     expression_context_block = get_selected_block (&expression_context_pc);
  
    expout_size = 10;
    expout_ptr = 0;
--- 1076,1102 ----
    old_chain = make_cleanup (free_funcalls, 0 /*ignore*/);
    funcall_chain = 0;
  
+   /* If no context specified, try using the current frame, if any. */
+ 
+   if (!block)
+     block = get_selected_block (&expression_context_pc);
+ 
+   /* Fall back to using the current source static context, if any. */
+ 
+   if (!block)
+     {
+       struct symtab_and_line cursal = get_current_source_symtab_and_line ();
+       if (cursal.symtab)
+ 	block = BLOCKVECTOR_BLOCK (BLOCKVECTOR (cursal.symtab), STATIC_BLOCK);
+     }
+ 
+   /* Save the context, if specified by caller, or found above. */
+ 
    if (block)
      {
        expression_context_block = block;
        expression_context_pc = BLOCK_START (block);
      }
  
    expout_size = 10;
    expout_ptr = 0;

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

[Fred Fish]

On Monday 23 January 2006 15:45, Jim Blandy wrote:
> On 1/23/06, Fred Fish <fnf@specifix.com> wrote:
> > This is why I think the correct and complete solution is to allow the
> > user to directly specify the context.
> 
> Sure.  That would entail extending the 'type_exp' non-terminal to have
> a FILENAME COLONCOLON TYPE production.  Sounds like the right thing.

The below patch seems to fix ptype and whatis to allow the
'file'::typename syntax, without breaking anything else and also
simplifying ptype_command.

Comments?

-Fred

================================================================================

Gdb ChangeLog entry:

	2006-02-10  Fred Fish  <fnf@specifix.com>

	* typeprint.c (whatis_exp): Initialize type to NULL.  Call
	ptype_eval for special cases, before evaluate_type.  Call
	value_type only if we haven't found a type already.
	(ptype_eval): Handle OP_VAR_VALUE as a special case, in addition
	to OP_TYPE.  This handles 'file'::typename expressions.
	(ptype_command): Replace entire function body with call to
	whatis_exp.
	

Testsuite ChangeLog entry:

	2006-02-10  Fred Fish  <fnf@specifix.com>

	* gdb.base/ptype.c: Add afoo for typedef checks.
	* gdb.base/ptype1.c: Add afoo for typedef checks.
	* gdb.base/whatis.c: Add typedef foo and var afoo.

	* gdb.base/ptype.exp: Add tests for 'file'::symbol
	and 'file'::typename syntax.
	* gdb.base/whatis.exp: Ditto.
 

Index: typeprint.c
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/typeprint.c,v
retrieving revision 1.1.1.2
diff -c -p -r1.1.1.2 typeprint.c
*** typeprint.c	30 Dec 2005 18:53:06 -0000	1.1.1.2
--- typeprint.c	10 Feb 2006 23:20:45 -0000
*************** whatis_exp (char *exp, int show)
*** 119,125 ****
    struct value *val;
    struct cleanup *old_chain = NULL;
    struct type *real_type = NULL;
!   struct type *type;
    int full = 0;
    int top = -1;
    int using_enc = 0;
--- 119,125 ----
    struct value *val;
    struct cleanup *old_chain = NULL;
    struct type *real_type = NULL;
!   struct type *type = NULL;
    int full = 0;
    int top = -1;
    int using_enc = 0;
*************** whatis_exp (char *exp, int show)
*** 128,139 ****
      {
        expr = parse_expression (exp);
        old_chain = make_cleanup (free_current_contents, &expr);
!       val = evaluate_type (expr);
      }
    else
      val = access_value_history (0);
  
!   type = value_type (val);
  
    if (objectprint)
      {
--- 128,142 ----
      {
        expr = parse_expression (exp);
        old_chain = make_cleanup (free_current_contents, &expr);
!       type = ptype_eval (expr);
!       if (type == NULL)
! 	val = evaluate_type (expr);
      }
    else
      val = access_value_history (0);
  
!   if (type == NULL)
!     type = value_type (val);
  
    if (objectprint)
      {
*************** ptype_eval (struct expression *exp)
*** 191,196 ****
--- 194,203 ----
      {
        return (exp->elts[1].type);
      }
+   else if (exp->elts[0].opcode == OP_VAR_VALUE)
+     {
+       return (SYMBOL_TYPE (exp->elts[2].symbol));
+     }
    else
      {
        return (NULL);
*************** ptype_eval (struct expression *exp)
*** 202,236 ****
  static void
  ptype_command (char *typename, int from_tty)
  {
!   struct type *type;
!   struct expression *expr;
!   struct cleanup *old_chain;
! 
!   if (typename == NULL)
!     {
!       /* Print type of last thing in value history. */
!       whatis_exp (typename, 1);
!     }
!   else
!     {
!       expr = parse_expression (typename);
!       old_chain = make_cleanup (free_current_contents, &expr);
!       type = ptype_eval (expr);
!       if (type != NULL)
! 	{
! 	  /* User did "ptype <typename>" */
! 	  printf_filtered ("type = ");
! 	  type_print (type, "", gdb_stdout, 1);
! 	  printf_filtered ("\n");
! 	  do_cleanups (old_chain);
! 	}
!       else
! 	{
! 	  /* User did "ptype <symbolname>" */
! 	  do_cleanups (old_chain);
! 	  whatis_exp (typename, 1);
! 	}
!     }
  }
  
  /* Print integral scalar data VAL, of type TYPE, onto stdio stream STREAM.
--- 209,215 ----
  static void
  ptype_command (char *typename, int from_tty)
  {
!   whatis_exp (typename, 1);
  }
  
  /* Print integral scalar data VAL, of type TYPE, onto stdio stream STREAM.
Index: testsuite/gdb.base/ptype.c
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/testsuite/gdb.base/ptype.c,v
retrieving revision 1.1.1.2
diff -c -p -r1.1.1.2 ptype.c
*** testsuite/gdb.base/ptype.c	8 Jan 2006 20:37:18 -0000	1.1.1.2
--- testsuite/gdb.base/ptype.c	10 Feb 2006 21:38:14 -0000
*************** func_type v_func_type;
*** 260,265 ****
--- 260,266 ----
  /***********/
  
  typedef int foo;
+ static foo afoo = 2;
  
  foo intfoo (afoo)
  {
Index: testsuite/gdb.base/ptype.exp
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/testsuite/gdb.base/ptype.exp,v
retrieving revision 1.1.1.2
diff -c -p -r1.1.1.2 ptype.exp
*** testsuite/gdb.base/ptype.exp	8 Jan 2006 20:37:19 -0000	1.1.1.2
--- testsuite/gdb.base/ptype.exp	10 Feb 2006 21:41:38 -0000
*************** gdb_test "list intfoo" ""
*** 593,598 ****
--- 593,603 ----
  gdb_test "ptype foo" "type = int" "ptype foo typedef after second list of intfoo"
  gdb_test "list charfoo" ""
  gdb_test "ptype foo" "type = char" "ptype foo typedef after second list of charfoo"
+ # Test the 'file'::exp syntax for variables and types
+ gdb_test "ptype 'ptype.c'::afoo" "type = int" "ptype 'file'::symbol"
+ gdb_test "ptype 'ptype.c'::foo" "type = int" "ptype 'file'::typename"
+ gdb_test "ptype 'ptype1.c'::afoo" "type = char" "ptype 'file'::symbol"
+ gdb_test "ptype 'ptype1.c'::foo" "type = char" "ptype 'file'::typename"
  
  # Test printing type of string constants and array constants, but
  # requires a running process.  These call malloc, and can take a long
Index: testsuite/gdb.base/ptype1.c
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/testsuite/gdb.base/ptype1.c,v
retrieving revision 1.1.1.1
diff -c -p -r1.1.1.1 ptype1.c
*** testsuite/gdb.base/ptype1.c	8 Jan 2006 20:37:18 -0000	1.1.1.1
--- testsuite/gdb.base/ptype1.c	10 Feb 2006 21:37:55 -0000
***************
*** 1,4 ****
--- 1,5 ----
  typedef char foo;
+ static foo afoo = 1;
  
  foo charfoo (afoo)
  {
Index: testsuite/gdb.base/whatis.c
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/testsuite/gdb.base/whatis.c,v
retrieving revision 1.1.1.1
diff -c -p -r1.1.1.1 whatis.c
*** testsuite/gdb.base/whatis.c	8 Oct 2005 19:36:19 -0000	1.1.1.1
--- testsuite/gdb.base/whatis.c	10 Feb 2006 21:35:00 -0000
*************** unsigned long	v_unsigned_long;
*** 46,51 ****
--- 46,54 ----
  float		v_float;
  double		v_double;
  
+ typedef int foo;
+ static foo afoo = 1;
+ 
  /*
   *	Now some derived types, which are arrays, functions-returning,
   *	pointers, structures, unions, and enumerations.
Index: testsuite/gdb.base/whatis.exp
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/testsuite/gdb.base/whatis.exp,v
retrieving revision 1.1.1.1
diff -c -p -r1.1.1.1 whatis.exp
*** testsuite/gdb.base/whatis.exp	8 Oct 2005 19:36:19 -0000	1.1.1.1
--- testsuite/gdb.base/whatis.exp	10 Feb 2006 21:35:51 -0000
*************** gdb_test "whatis nested_su.inner_union_i
*** 402,404 ****
--- 402,414 ----
  gdb_test "whatis nested_su.inner_union_instance.inner_union_int" \
      "type = int" \
      "whatis inner union member"
+ 
+ # Test the 'file'::exp syntax for variables and types
+ 
+ gdb_test "whatis 'whatis.c'::afoo" \
+     "type = foo" \
+     "whatis 'file'::symbol"
+ 
+ gdb_test "whatis 'whatis.c'::foo" \
+     "type = int" \
+     "whatis 'file'::typename"

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

[Fred Fish]

On Monday 23 January 2006 15:45, Jim Blandy wrote:
> On 1/23/06, Fred Fish <fnf@specifix.com> wrote:
> > This is why I think the correct and complete solution is to allow the
> > user to directly specify the context.
> 
> Sure.  That would entail extending the 'type_exp' non-terminal to have
> a FILENAME COLONCOLON TYPE production.  Sounds like the right thing.

The below patch seems to fix ptype and whatis to allow the
'file'::typename syntax, without breaking anything else and also
simplifying ptype_command.

Comments?

-Fred

================================================================================

Gdb ChangeLog entry:

	2006-02-10  Fred Fish  <fnf@specifix.com>

	* typeprint.c (whatis_exp): Initialize type to NULL.  Call
	ptype_eval for special cases, before evaluate_type.  Call
	value_type only if we haven't found a type already.
	(ptype_eval): Handle OP_VAR_VALUE as a special case, in addition
	to OP_TYPE.  This handles 'file'::typename expressions.
	(ptype_command): Replace entire function body with call to
	whatis_exp.
	

Testsuite ChangeLog entry:

	2006-02-10  Fred Fish  <fnf@specifix.com>

	* gdb.base/ptype.c: Add afoo for typedef checks.
	* gdb.base/ptype1.c: Add afoo for typedef checks.
	* gdb.base/whatis.c: Add typedef foo and var afoo.

	* gdb.base/ptype.exp: Add tests for 'file'::symbol
	and 'file'::typename syntax.
	* gdb.base/whatis.exp: Ditto.
 

Index: typeprint.c
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/typeprint.c,v
retrieving revision 1.1.1.2
diff -c -p -r1.1.1.2 typeprint.c
*** typeprint.c	30 Dec 2005 18:53:06 -0000	1.1.1.2
--- typeprint.c	10 Feb 2006 23:20:45 -0000
*************** whatis_exp (char *exp, int show)
*** 119,125 ****
    struct value *val;
    struct cleanup *old_chain = NULL;
    struct type *real_type = NULL;
!   struct type *type;
    int full = 0;
    int top = -1;
    int using_enc = 0;
--- 119,125 ----
    struct value *val;
    struct cleanup *old_chain = NULL;
    struct type *real_type = NULL;
!   struct type *type = NULL;
    int full = 0;
    int top = -1;
    int using_enc = 0;
*************** whatis_exp (char *exp, int show)
*** 128,139 ****
      {
        expr = parse_expression (exp);
        old_chain = make_cleanup (free_current_contents, &expr);
!       val = evaluate_type (expr);
      }
    else
      val = access_value_history (0);
  
!   type = value_type (val);
  
    if (objectprint)
      {
--- 128,142 ----
      {
        expr = parse_expression (exp);
        old_chain = make_cleanup (free_current_contents, &expr);
!       type = ptype_eval (expr);
!       if (type == NULL)
! 	val = evaluate_type (expr);
      }
    else
      val = access_value_history (0);
  
!   if (type == NULL)
!     type = value_type (val);
  
    if (objectprint)
      {
*************** ptype_eval (struct expression *exp)
*** 191,196 ****
--- 194,203 ----
      {
        return (exp->elts[1].type);
      }
+   else if (exp->elts[0].opcode == OP_VAR_VALUE)
+     {
+       return (SYMBOL_TYPE (exp->elts[2].symbol));
+     }
    else
      {
        return (NULL);
*************** ptype_eval (struct expression *exp)
*** 202,236 ****
  static void
  ptype_command (char *typename, int from_tty)
  {
!   struct type *type;
!   struct expression *expr;
!   struct cleanup *old_chain;
! 
!   if (typename == NULL)
!     {
!       /* Print type of last thing in value history. */
!       whatis_exp (typename, 1);
!     }
!   else
!     {
!       expr = parse_expression (typename);
!       old_chain = make_cleanup (free_current_contents, &expr);
!       type = ptype_eval (expr);
!       if (type != NULL)
! 	{
! 	  /* User did "ptype <typename>" */
! 	  printf_filtered ("type = ");
! 	  type_print (type, "", gdb_stdout, 1);
! 	  printf_filtered ("\n");
! 	  do_cleanups (old_chain);
! 	}
!       else
! 	{
! 	  /* User did "ptype <symbolname>" */
! 	  do_cleanups (old_chain);
! 	  whatis_exp (typename, 1);
! 	}
!     }
  }
  
  /* Print integral scalar data VAL, of type TYPE, onto stdio stream STREAM.
--- 209,215 ----
  static void
  ptype_command (char *typename, int from_tty)
  {
!   whatis_exp (typename, 1);
  }
  
  /* Print integral scalar data VAL, of type TYPE, onto stdio stream STREAM.
Index: testsuite/gdb.base/ptype.c
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/testsuite/gdb.base/ptype.c,v
retrieving revision 1.1.1.2
diff -c -p -r1.1.1.2 ptype.c
*** testsuite/gdb.base/ptype.c	8 Jan 2006 20:37:18 -0000	1.1.1.2
--- testsuite/gdb.base/ptype.c	10 Feb 2006 21:38:14 -0000
*************** func_type v_func_type;
*** 260,265 ****
--- 260,266 ----
  /***********/
  
  typedef int foo;
+ static foo afoo = 2;
  
  foo intfoo (afoo)
  {
Index: testsuite/gdb.base/ptype.exp
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/testsuite/gdb.base/ptype.exp,v
retrieving revision 1.1.1.2
diff -c -p -r1.1.1.2 ptype.exp
*** testsuite/gdb.base/ptype.exp	8 Jan 2006 20:37:19 -0000	1.1.1.2
--- testsuite/gdb.base/ptype.exp	10 Feb 2006 21:41:38 -0000
*************** gdb_test "list intfoo" ""
*** 593,598 ****
--- 593,603 ----
  gdb_test "ptype foo" "type = int" "ptype foo typedef after second list of intfoo"
  gdb_test "list charfoo" ""
  gdb_test "ptype foo" "type = char" "ptype foo typedef after second list of charfoo"
+ # Test the 'file'::exp syntax for variables and types
+ gdb_test "ptype 'ptype.c'::afoo" "type = int" "ptype 'file'::symbol"
+ gdb_test "ptype 'ptype.c'::foo" "type = int" "ptype 'file'::typename"
+ gdb_test "ptype 'ptype1.c'::afoo" "type = char" "ptype 'file'::symbol"
+ gdb_test "ptype 'ptype1.c'::foo" "type = char" "ptype 'file'::typename"
  
  # Test printing type of string constants and array constants, but
  # requires a running process.  These call malloc, and can take a long
Index: testsuite/gdb.base/ptype1.c
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/testsuite/gdb.base/ptype1.c,v
retrieving revision 1.1.1.1
diff -c -p -r1.1.1.1 ptype1.c
*** testsuite/gdb.base/ptype1.c	8 Jan 2006 20:37:18 -0000	1.1.1.1
--- testsuite/gdb.base/ptype1.c	10 Feb 2006 21:37:55 -0000
***************
*** 1,4 ****
--- 1,5 ----
  typedef char foo;
+ static foo afoo = 1;
  
  foo charfoo (afoo)
  {
Index: testsuite/gdb.base/whatis.c
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/testsuite/gdb.base/whatis.c,v
retrieving revision 1.1.1.1
diff -c -p -r1.1.1.1 whatis.c
*** testsuite/gdb.base/whatis.c	8 Oct 2005 19:36:19 -0000	1.1.1.1
--- testsuite/gdb.base/whatis.c	10 Feb 2006 21:35:00 -0000
*************** unsigned long	v_unsigned_long;
*** 46,51 ****
--- 46,54 ----
  float		v_float;
  double		v_double;
  
+ typedef int foo;
+ static foo afoo = 1;
+ 
  /*
   *	Now some derived types, which are arrays, functions-returning,
   *	pointers, structures, unions, and enumerations.
Index: testsuite/gdb.base/whatis.exp
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/testsuite/gdb.base/whatis.exp,v
retrieving revision 1.1.1.1
diff -c -p -r1.1.1.1 whatis.exp
*** testsuite/gdb.base/whatis.exp	8 Oct 2005 19:36:19 -0000	1.1.1.1
--- testsuite/gdb.base/whatis.exp	10 Feb 2006 21:35:51 -0000
*************** gdb_test "whatis nested_su.inner_union_i
*** 402,404 ****
--- 402,414 ----
  gdb_test "whatis nested_su.inner_union_instance.inner_union_int" \
      "type = int" \
      "whatis inner union member"
+ 
+ # Test the 'file'::exp syntax for variables and types
+ 
+ gdb_test "whatis 'whatis.c'::afoo" \
+     "type = foo" \
+     "whatis 'file'::symbol"
+ 
+ gdb_test "whatis 'whatis.c'::foo" \
+     "type = int" \
+     "whatis 'file'::typename"

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

[Daniel Jacobowitz]

On Fri, Feb 10, 2006 at 07:35:06PM -0500, Fred Fish wrote:
> On Monday 23 January 2006 15:45, Jim Blandy wrote:
> > On 1/23/06, Fred Fish <fnf@specifix.com> wrote:
> > > This is why I think the correct and complete solution is to allow the
> > > user to directly specify the context.
> > 
> > Sure.  That would entail extending the 'type_exp' non-terminal to have
> > a FILENAME COLONCOLON TYPE production.  Sounds like the right thing.
> 
> The below patch seems to fix ptype and whatis to allow the
> 'file'::typename syntax, without breaking anything else and also
> simplifying ptype_command.
> 
> Comments?

Don't you get a warning compiling this?  It looks to me like, with
objectprint set, ptype and whatis will now blow up; they call
value_rtti_target_type without initializing val.

Also ptype will now do the RTTI lookup; I'm not sure whether it should
or not.  The documentation for whatis and ptype leaves me way
unenlightened about what the difference between them is supposed to
be; perhaps we should eliminate the difference.


-- 
Daniel Jacobowitz
CodeSourcery

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

[Eli Zaretskii]

> Date: Sat, 11 Feb 2006 13:35:00 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Jim Blandy <jimb@red-bean.com>, gdb-patches@sourceware.org
> 
> The documentation for whatis and ptype leaves me way unenlightened
> about what the difference between them is supposed to be; perhaps we
> should eliminate the difference.

Is the following excerpt from the manual incorrect?  If it's correct,
it seems to answer your question:

    @item ptype @var{expr}
    @itemx ptype
    Print a description of the type of expression @var{expr}.  @code{ptype}
    differs from @code{whatis} by printing a detailed description, instead
    of just the name of the type.

    For example, for this variable declaration:

    @smallexample
    struct complex @{double real; double imag;@} v;
    @end smallexample

    @noindent
    the two commands give this output:

    @smallexample
    @group
    (@value{GDBP}) whatis v
    type = struct complex
    (@value{GDBP}) ptype v
    type = struct complex @{
	double real;
	double imag;
    @}
    @end group
    @end smallexample

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

[Fred Fish]

On Saturday 11 February 2006 13:35, Daniel Jacobowitz wrote:
> Don't you get a warning compiling this?

No, I was building without -O, for better debugging of gdb, and that produces
the warning:

  cc1: warning: -Wuninitialized is not supported without -O

for every file, which I ignore.  Building with -O does indeed produce a
warning about val being uninitialized.

> It looks to me like, with objectprint set, ptype and whatis will now
> blow up; they call value_rtti_target_type without initializing val.

Yup.  The fix would be to remove the test of type==NULL and always
initialize val, whether or not ptype_eval finds a type to print.

Apparently we don't have any test in the gdb testsuite that checks
using objectprint, as there we no regressions when I ran it after the
change.

> Also ptype will now do the RTTI lookup; I'm not sure whether it
> should or not.

Not sure either, now that you point it out.

> The documentation for whatis and ptype leaves me way unenlightened
> about what the difference between them is supposed to be; perhaps we
> should eliminate the difference.

Mainly it appears that ptype is expected to print the entire type,
while whatis simply prints the basic info.  I.E.

    (gdb) ptype afoo
    type = struct foo {
        int x;
        int y;
    }

    (gdb) whatis afoo
    type = struct foo
    (gdb)

If we want to keep ptype from doing the RTTI lookup when objectprint is
set, it's easy enough to revert the part of the patch that simplifies
ptype_command into a simple call to whatis_exp.  The meat of the change
that makes "ptype 'foo.c'::afoo" work is the change to ptype_eval to
add the test for an OP_VAR_VALUE expression.  We should probably still
keep the patch to whatis_exp, with the fix to avoid a NULL val of course,
so that both ptype and whatis can use the 'file'::typename syntax.

-Fred

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

[Daniel Jacobowitz]

On Sat, Feb 11, 2006 at 09:08:10PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 11 Feb 2006 13:35:00 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Jim Blandy <jimb@red-bean.com>, gdb-patches@sourceware.org
> > 
> > The documentation for whatis and ptype leaves me way unenlightened
> > about what the difference between them is supposed to be; perhaps we
> > should eliminate the difference.
> 
> Is the following excerpt from the manual incorrect?  If it's correct,
> it seems to answer your question:

Ah - I missed that.  There's nothing that explains this _other_
difference between them, which suggests that we should indeed remove
it (remove the difference, I mean).

-- 
Daniel Jacobowitz
CodeSourcery

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

[Daniel Jacobowitz]

On Sat, Feb 11, 2006 at 03:01:01PM -0500, Fred Fish wrote:
> > It looks to me like, with objectprint set, ptype and whatis will now
> > blow up; they call value_rtti_target_type without initializing val.
> 
> Yup.  The fix would be to remove the test of type==NULL and always
> initialize val, whether or not ptype_eval finds a type to print.

Well, if the results of ptype_eval and evaluate_type are inconsistent
here, won't the result of doing this be meaningless?  And if they were
already consistent, then I'm a little confused how your patch works.

Actually I think I'm a little confused either way.

If ptype_eval failed evaluate_type would eventually get called,
and that ought to handle OP_VAR_VALUE just fine.

> Apparently we don't have any test in the gdb testsuite that checks
> using objectprint, as there we no regressions when I ran it after the
> change.

Yes, unfortunately, I suspect this is true.

> > Also ptype will now do the RTTI lookup; I'm not sure whether it
> > should or not.
> 
> Not sure either, now that you point it out.

Might as well let it.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Fred Fish]

On Saturday 11 February 2006 15:20, Daniel Jacobowitz wrote:
> Well, if the results of ptype_eval and evaluate_type are inconsistent
> here, won't the result of doing this be meaningless?  And if they were
> already consistent, then I'm a little confused how your patch works.

ptype_eval extracted the type directly from the expression, while
evaluate_type creates a value, which it wasn't prepared to do from
just a typedef name.

In any case, I think I found a better solution, which is basically to
eliminate ptype_eval and let the expression evaluator create a value
with the right type.  The actual value isn't important, since we're
only going to use it's type.  This is how the ADA expression evaluator
handles evaluating an OP_TYPE expression.

> > > Also ptype will now do the RTTI lookup; I'm not sure whether it
> > > should or not.
> > 
> > Not sure either, now that you point it out.
> 
> Might as well let it.

OK, then we can let whatis_exp handle both ptype and whatis.

Attached is a reworked patch, with a couple of additional testsuite
changes.

-Fred

Gdb ChangeLog entry:

	2006-02-12  Fred Fish  <fnf@specifix.com>

	* eval.c (evaluate_subexp_standard): For OP_VAR_VALUE, if exp
	is a typedef, return a non lval value zero, of the appropriate
	type, when avoiding side effects.
	For OP_TYPE, return a non lval value zero, of the appropriate
	type, when avoiding side effects.
	* typeprint.c (ptype_eval): Remove function and declaration.
	(ptype_command): Simplify to just a call to whatis_exp.
 	

Testsuite ChangeLog entry:

	2006-02-12  Fred Fish  <fnf@specifix.com>

	* gdb.base/ptype.c: Add afoo for typedef checks.
	* gdb.base/ptype1.c: Add afoo for typedef checks.
	* gdb.base/whatis.c: Add typedef foo and var afoo.

	* gdb.base/ptype.exp: Add tests for 'file'::symbol and
	'file'::typename syntax.  Add tests using value history.
	* gdb.base/whatis.exp: Ditto.

Index: eval.c
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/eval.c,v
retrieving revision 1.1.1.2
diff -c -p -r1.1.1.2 eval.c
*** eval.c	30 Dec 2005 18:53:04 -0000	1.1.1.2
--- eval.c	12 Feb 2006 18:07:29 -0000
*************** evaluate_subexp_standard (struct type *e
*** 461,466 ****
--- 461,472 ----
  	 value_rtti_target_type () if we are dealing with a pointer
  	 or reference to a base class and print object is on. */
  
+       /* If asked to evaluate a typedef, and we are avoiding side effects,
+ 	 then create a value of the appropriate type to return. */
+       if (noside == EVAL_AVOID_SIDE_EFFECTS
+ 	  && SYMBOL_CLASS (exp->elts[pc + 2].symbol) == LOC_TYPEDEF)
+ 	return (allocate_value (SYMBOL_TYPE (exp->elts[2].symbol)));
+       else
  	return value_of_variable (exp->elts[pc + 2].symbol,
  				  exp->elts[pc + 1].block);
  
*************** evaluate_subexp_standard (struct type *e
*** 2086,2092 ****
        return value_of_local ("self", 1);
  
      case OP_TYPE:
!       error (_("Attempt to use a type name as an expression"));
  
      default:
        /* Removing this case and compiling with gcc -Wall reveals that
--- 2092,2106 ----
        return value_of_local ("self", 1);
  
      case OP_TYPE:
!       /* The value is not supposed to be used.  This is here to make it
!          easier to accommodate expressions that contain types.  */
!       (*pos) += 2;
!       if (noside == EVAL_SKIP)
!         goto nosideret;
!       else if (noside == EVAL_AVOID_SIDE_EFFECTS)
!         return allocate_value (exp->elts[pc + 1].type);
!       else
!         error (_("Attempt to use a type name as an expression"));
  
      default:
        /* Removing this case and compiling with gcc -Wall reveals that
Index: typeprint.c
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/typeprint.c,v
retrieving revision 1.1.1.2
diff -c -p -r1.1.1.2 typeprint.c
*** typeprint.c	30 Dec 2005 18:53:06 -0000	1.1.1.2
--- typeprint.c	12 Feb 2006 18:07:29 -0000
*************** extern void _initialize_typeprint (void)
*** 45,52 ****
  
  static void ptype_command (char *, int);
  
- static struct type *ptype_eval (struct expression *);
- 
  static void whatis_command (char *, int);
  
  static void whatis_exp (char *, int);
--- 45,50 ----
*************** whatis_command (char *exp, int from_tty)
*** 182,236 ****
    whatis_exp (exp, -1);
  }
  
- /* Simple subroutine for ptype_command.  */
- 
- static struct type *
- ptype_eval (struct expression *exp)
- {
-   if (exp->elts[0].opcode == OP_TYPE)
-     {
-       return (exp->elts[1].type);
-     }
-   else
-     {
-       return (NULL);
-     }
- }
- 
  /* TYPENAME is either the name of a type, or an expression.  */
  
  static void
  ptype_command (char *typename, int from_tty)
  {
!   struct type *type;
!   struct expression *expr;
!   struct cleanup *old_chain;
! 
!   if (typename == NULL)
!     {
!       /* Print type of last thing in value history. */
!       whatis_exp (typename, 1);
!     }
!   else
!     {
!       expr = parse_expression (typename);
!       old_chain = make_cleanup (free_current_contents, &expr);
!       type = ptype_eval (expr);
!       if (type != NULL)
! 	{
! 	  /* User did "ptype <typename>" */
! 	  printf_filtered ("type = ");
! 	  type_print (type, "", gdb_stdout, 1);
! 	  printf_filtered ("\n");
! 	  do_cleanups (old_chain);
! 	}
!       else
! 	{
! 	  /* User did "ptype <symbolname>" */
! 	  do_cleanups (old_chain);
! 	  whatis_exp (typename, 1);
! 	}
!     }
  }
  
  /* Print integral scalar data VAL, of type TYPE, onto stdio stream STREAM.
--- 180,191 ----
    whatis_exp (exp, -1);
  }
  
  /* TYPENAME is either the name of a type, or an expression.  */
  
  static void
  ptype_command (char *typename, int from_tty)
  {
!   whatis_exp (typename, 1);
  }
  
  /* Print integral scalar data VAL, of type TYPE, onto stdio stream STREAM.
Index: testsuite/gdb.base/ptype.c
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/testsuite/gdb.base/ptype.c,v
retrieving revision 1.1.1.2
diff -c -p -r1.1.1.2 ptype.c
*** testsuite/gdb.base/ptype.c	8 Jan 2006 20:37:18 -0000	1.1.1.2
--- testsuite/gdb.base/ptype.c	10 Feb 2006 21:38:14 -0000
*************** func_type v_func_type;
*** 260,265 ****
--- 260,266 ----
  /***********/
  
  typedef int foo;
+ static foo afoo = 2;
  
  foo intfoo (afoo)
  {
Index: testsuite/gdb.base/ptype.exp
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/testsuite/gdb.base/ptype.exp,v
retrieving revision 1.1.1.2
diff -c -p -r1.1.1.2 ptype.exp
*** testsuite/gdb.base/ptype.exp	8 Jan 2006 20:37:19 -0000	1.1.1.2
--- testsuite/gdb.base/ptype.exp	12 Feb 2006 12:54:42 -0000
*************** gdb_test "list intfoo" ""
*** 593,598 ****
--- 593,610 ----
  gdb_test "ptype foo" "type = int" "ptype foo typedef after second list of intfoo"
  gdb_test "list charfoo" ""
  gdb_test "ptype foo" "type = char" "ptype foo typedef after second list of charfoo"
+ # Test the 'file'::exp syntax for variables and types
+ gdb_test "ptype 'ptype.c'::afoo" "type = int" "ptype 'file'::symbol"
+ gdb_test "ptype 'ptype.c'::foo" "type = int" "ptype 'file'::typename"
+ gdb_test "ptype 'ptype1.c'::afoo" "type = char" "ptype 'file'::symbol"
+ gdb_test "ptype 'ptype1.c'::foo" "type = char" "ptype 'file'::typename"
+ 
+ # Test printing value history type
+ 
+ gdb_test "p (long)1" ""
+ gdb_test "ptype" "type = long" "ptype long value from value history"
+ gdb_test "p (short)1" ""
+ gdb_test "ptype" "type = short" "ptype short value from value history"
  
  # Test printing type of string constants and array constants, but
  # requires a running process.  These call malloc, and can take a long
Index: testsuite/gdb.base/ptype1.c
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/testsuite/gdb.base/ptype1.c,v
retrieving revision 1.1.1.1
diff -c -p -r1.1.1.1 ptype1.c
*** testsuite/gdb.base/ptype1.c	8 Jan 2006 20:37:18 -0000	1.1.1.1
--- testsuite/gdb.base/ptype1.c	10 Feb 2006 21:37:55 -0000
***************
*** 1,4 ****
--- 1,5 ----
  typedef char foo;
+ static foo afoo = 1;
  
  foo charfoo (afoo)
  {
Index: testsuite/gdb.base/whatis.c
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/testsuite/gdb.base/whatis.c,v
retrieving revision 1.1.1.1
diff -c -p -r1.1.1.1 whatis.c
*** testsuite/gdb.base/whatis.c	8 Oct 2005 19:36:19 -0000	1.1.1.1
--- testsuite/gdb.base/whatis.c	10 Feb 2006 21:35:00 -0000
*************** unsigned long	v_unsigned_long;
*** 46,51 ****
--- 46,54 ----
  float		v_float;
  double		v_double;
  
+ typedef int foo;
+ static foo afoo = 1;
+ 
  /*
   *	Now some derived types, which are arrays, functions-returning,
   *	pointers, structures, unions, and enumerations.
Index: testsuite/gdb.base/whatis.exp
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/testsuite/gdb.base/whatis.exp,v
retrieving revision 1.1.1.1
diff -c -p -r1.1.1.1 whatis.exp
*** testsuite/gdb.base/whatis.exp	8 Oct 2005 19:36:19 -0000	1.1.1.1
--- testsuite/gdb.base/whatis.exp	12 Feb 2006 12:55:26 -0000
*************** gdb_test "whatis nested_su.inner_union_i
*** 402,404 ****
--- 402,421 ----
  gdb_test "whatis nested_su.inner_union_instance.inner_union_int" \
      "type = int" \
      "whatis inner union member"
+ 
+ # Test the 'file'::exp syntax for variables and types
+ 
+ gdb_test "whatis 'whatis.c'::afoo" \
+     "type = foo" \
+     "whatis 'file'::symbol"
+ 
+ gdb_test "whatis 'whatis.c'::foo" \
+     "type = int" \
+     "whatis 'file'::typename"
+ 
+ # Test printing value history type
+ 
+ gdb_test "p (long)1" ""
+ gdb_test "whatis" "type = long" "whatis long value from value history"
+ gdb_test "p (short)1" ""
+ gdb_test "whatis" "type = short" "whatis short value from value history"

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

[Daniel Jacobowitz]

On Sun, Feb 12, 2006 at 01:49:06PM -0500, Fred Fish wrote:
> *** eval.c	30 Dec 2005 18:53:04 -0000	1.1.1.2
> --- eval.c	12 Feb 2006 18:07:29 -0000
> *************** evaluate_subexp_standard (struct type *e
> *** 461,466 ****
> --- 461,472 ----
>   	 value_rtti_target_type () if we are dealing with a pointer
>   	 or reference to a base class and print object is on. */
>   
> +       /* If asked to evaluate a typedef, and we are avoiding side effects,
> + 	 then create a value of the appropriate type to return. */
> +       if (noside == EVAL_AVOID_SIDE_EFFECTS
> + 	  && SYMBOL_CLASS (exp->elts[pc + 2].symbol) == LOC_TYPEDEF)
> + 	return (allocate_value (SYMBOL_TYPE (exp->elts[2].symbol)));
> +       else
>   	return value_of_variable (exp->elts[pc + 2].symbol,
>   				  exp->elts[pc + 1].block);
>   

This patch seems OK to me; but we really ought to fix up the comment
directly above this code that you're changing.

      /* JYG: We used to just return value_zero of the symbol type
         if we're asked to avoid side effects.  Otherwise we return
         value_of_variable (...).  However I'm not sure if
         value_of_variable () has any side effect.
         We need a full value object returned here for whatis_exp ()
         to call evaluate_type () and then pass the full value to
         value_rtti_target_type () if we are dealing with a pointer
         or reference to a base class and print object is on. */

It'd be nice to mention "so now we only do this for typedefs".

-- 
Daniel Jacobowitz
CodeSourcery

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

[Fred Fish]

On Tuesday 14 February 2006 09:10, Daniel Jacobowitz wrote:
> This patch seems OK to me

While doing some further testing I discovered that it doesn't handle type names
with whitespace, such as:

	(gdb) ptype 'foo.c'::struct bar

so I'm going to work on it some more.  It's starting to look like it
is going to require some work on the parser after all.

-Fred

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

[Fred Fish]

On Tuesday 14 February 2006 09:10, Daniel Jacobowitz wrote:
> This patch seems OK to me; but we really ought to fix up the comment
> directly above this code that you're changing.

I've think it would be best to split work on this issue up into two parts

(1) Make ptype and whatis handle the same arguments.  Currently ptype
will work on typedefs, but whatis does not.  This is the change that
makes them both use whatis_exp and eliminates ptype_eval.

(2) Make ptype and whatis handle printing types specified in a given
context using 'file'::type.  I have a fix that involves a fairly
minor change to the parser and makes the patch you are commenting on
obsolete.

Here is the patch for (1).  I believe we previously reached on consensus
that this change was OK, so I'd like to get it checked in.  I added some
testsuite support for testing how whatis behaves with typedef names.

Gdb ChangeLog entry:

	2006-02-16  Fred Fish  <fnf@specifix.com>

	* eval.c (evaluate_subexp_standard):  For OP_TYPE, return
 	a non lval value zero, of the appropriate type, when avoiding
	side effects.
	* typeprint.c (ptype_eval): Remove function and declaration.
	(ptype_command): Simplify to just a call to whatis_exp.
 
Testsuite ChangeLog entry:

	2006-02-16  Fred Fish  <fnf@specifix.com>

	* gdb.base/whatis.c: Define variables using typedefs char_addr,
	ushort_addr, and slong_addr, so the typedefs are not optimized
	away.
	* gdb.base/whatis.exp: Add tests using type name for struct type,
	union type, enum type, and typedef.
 	
Index: eval.c
===================================================================
RCS file: /cvs/src/src/gdb/eval.c,v
retrieving revision 1.60
diff -c -p -r1.60 eval.c
*** eval.c	17 Dec 2005 22:33:59 -0000	1.60
--- eval.c	16 Feb 2006 23:16:27 -0000
*************** evaluate_subexp_standard (struct type *e
*** 2086,2092 ****
        return value_of_local ("self", 1);
  
      case OP_TYPE:
!       error (_("Attempt to use a type name as an expression"));
  
      default:
        /* Removing this case and compiling with gcc -Wall reveals that
--- 2086,2100 ----
        return value_of_local ("self", 1);
  
      case OP_TYPE:
!       /* The value is not supposed to be used.  This is here to make it
!          easier to accommodate expressions that contain types.  */
!       (*pos) += 2;
!       if (noside == EVAL_SKIP)
!         goto nosideret;
!       else if (noside == EVAL_AVOID_SIDE_EFFECTS)
!         return allocate_value (exp->elts[pc + 1].type);
!       else
!         error (_("Attempt to use a type name as an expression"));
  
      default:
        /* Removing this case and compiling with gcc -Wall reveals that
Index: typeprint.c
===================================================================
RCS file: /cvs/src/src/gdb/typeprint.c,v
retrieving revision 1.25
diff -c -p -r1.25 typeprint.c
*** typeprint.c	17 Dec 2005 22:34:03 -0000	1.25
--- typeprint.c	16 Feb 2006 23:16:58 -0000
*************** extern void _initialize_typeprint (void)
*** 45,52 ****
  
  static void ptype_command (char *, int);
  
- static struct type *ptype_eval (struct expression *);
- 
  static void whatis_command (char *, int);
  
  static void whatis_exp (char *, int);
--- 45,50 ----
*************** whatis_command (char *exp, int from_tty)
*** 182,236 ****
    whatis_exp (exp, -1);
  }
  
- /* Simple subroutine for ptype_command.  */
- 
- static struct type *
- ptype_eval (struct expression *exp)
- {
-   if (exp->elts[0].opcode == OP_TYPE)
-     {
-       return (exp->elts[1].type);
-     }
-   else
-     {
-       return (NULL);
-     }
- }
- 
  /* TYPENAME is either the name of a type, or an expression.  */
  
  static void
  ptype_command (char *typename, int from_tty)
  {
!   struct type *type;
!   struct expression *expr;
!   struct cleanup *old_chain;
! 
!   if (typename == NULL)
!     {
!       /* Print type of last thing in value history. */
!       whatis_exp (typename, 1);
!     }
!   else
!     {
!       expr = parse_expression (typename);
!       old_chain = make_cleanup (free_current_contents, &expr);
!       type = ptype_eval (expr);
!       if (type != NULL)
! 	{
! 	  /* User did "ptype <typename>" */
! 	  printf_filtered ("type = ");
! 	  type_print (type, "", gdb_stdout, 1);
! 	  printf_filtered ("\n");
! 	  do_cleanups (old_chain);
! 	}
!       else
! 	{
! 	  /* User did "ptype <symbolname>" */
! 	  do_cleanups (old_chain);
! 	  whatis_exp (typename, 1);
! 	}
!     }
  }
  
  /* Print integral scalar data VAL, of type TYPE, onto stdio stream STREAM.
--- 180,191 ----
    whatis_exp (exp, -1);
  }
  
  /* TYPENAME is either the name of a type, or an expression.  */
  
  static void
  ptype_command (char *typename, int from_tty)
  {
!   whatis_exp (typename, 1);
  }
  
  /* Print integral scalar data VAL, of type TYPE, onto stdio stream STREAM.
Index: testsuite/gdb.base/whatis.c
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/whatis.c,v
retrieving revision 1.3
diff -c -p -r1.3 whatis.c
*** testsuite/gdb.base/whatis.c	23 Aug 2004 13:04:03 -0000	1.3
--- testsuite/gdb.base/whatis.c	16 Feb 2006 23:22:33 -0000
*************** double		v_double_array[2];
*** 79,86 ****
--- 79,89 ----
     a special case kludge in GDB (Unix system include files like to define
     caddr_t), but for a variety of types.  */
  typedef char *char_addr;
+ static char_addr a_char_addr;
  typedef unsigned short *ushort_addr;
+ static ushort_addr a_ushort_addr;
  typedef signed long *slong_addr;
+ static slong_addr a_slong_addr;
  
  char		*v_char_pointer;
  signed char	*v_signed_char_pointer;
Index: testsuite/gdb.base/whatis.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/whatis.exp,v
retrieving revision 1.6
diff -c -p -r1.6 whatis.exp
*** testsuite/gdb.base/whatis.exp	23 Aug 2004 13:04:03 -0000	1.6
--- testsuite/gdb.base/whatis.exp	16 Feb 2006 23:22:36 -0000
*************** gdb_test "whatis v_struct1" \
*** 273,278 ****
--- 273,282 ----
      "type = struct t_struct" \
      "whatis named structure"
  
+ gdb_test "whatis struct t_struct" \
+     "type = struct t_struct" \
+     "whatis named structure using type name"
+ 
  gdb_test "whatis v_struct2" \
      "type = struct \{$unstruct\}" \
      "whatis unnamed structure"
*************** gdb_test "whatis v_union" \
*** 283,288 ****
--- 287,296 ----
      "type = union t_union" \
      "whatis named union"
  
+ gdb_test "whatis union t_union" \
+     "type = union t_union" \
+     "whatis named union using type name"
+ 
  gdb_test "whatis v_union2" \
      "type = union \{$ununion\}" \
      "whatis unnamed union"
*************** gdb_test "whatis clunker" \
*** 371,376 ****
--- 379,388 ----
      "type = enum cars" \
      "whatis enumeration"
  
+ gdb_test "whatis enum cars" \
+     "type = enum cars" \
+     "whatis enumeration using type name"
+ 
  
  # test whatis command with nested struct and union
  gdb_test "whatis nested_su" \
*************** gdb_test "whatis nested_su.inner_union_i
*** 402,404 ****
--- 414,426 ----
  gdb_test "whatis nested_su.inner_union_instance.inner_union_int" \
      "type = int" \
      "whatis inner union member"
+ 
+ # test whatis command with typedefs
+ 
+ gdb_test "whatis char_addr" \
+     "type = char \\*" \
+     "whatis using typedef type name"
+ 
+ gdb_test "whatis a_char_addr" \
+     "type = char_addr" \
+     "whatis applied to variable defined by typedef"

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

[Eli Zaretskii]

> From: Fred Fish <fnf@diveadx.com>
> Date: Thu, 16 Feb 2006 19:16:00 -0500
> Cc: Jim Blandy <jimb@red-bean.com>, gdb-patches@sourceware.org
> 
> On Tuesday 14 February 2006 09:10, Daniel Jacobowitz wrote:
> > This patch seems OK to me; but we really ought to fix up the comment
> > directly above this code that you're changing.
> 
> I've think it would be best to split work on this issue up into two parts
> 
> (1) Make ptype and whatis handle the same arguments.  Currently ptype
> will work on typedefs, but whatis does not.  This is the change that
> makes them both use whatis_exp and eliminates ptype_eval.
> [...]
> Here is the patch for (1).
> [...]
> --- 180,191 ----
>     whatis_exp (exp, -1);
>   }
>   
>   /* TYPENAME is either the name of a type, or an expression.  */
>   
>   static void
>   ptype_command (char *typename, int from_tty)
>   {
> !   whatis_exp (typename, 1);
>   }

Will the manual's description of the differences between these two
commands be still valid after this change?

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

[Fred Fish]

On Friday 17 February 2006 04:15, Eli Zaretskii wrote:
> Will the manual's description of the differences between these two
> commands be still valid after this change?

The only difference between ptype and whatis, for the arguments that they
accept, will be whether the "detailed description" of the type is printed.

This is actually the current state of affairs even without the patch,
except that without the patch using whatis on type names will print:

  "Attempt to use a type name as an expression"

This patch basically simplifies the code and allows whatis to accept
type names.

With this patch, there are no changes in the gdb testsuite results,
other than the newly added tests pass (they fail without the code part
of the patch).

I'll make the appropriate doc changes and post a revised patch.

-Fred

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

[Fred Fish]

On Friday 17 February 2006 04:15, Eli Zaretskii wrote:
> Will the manual's description of the differences between these two
> commands be still valid after this change?

Here is a patch for the doc change.

If there aren't any objections, I'd like to get this patch and the
code/testsuite patch checked in ASAP and get back to work on the
parser change to accept the 'file'::typename syntax.

-Fred

2006-02-17  Fred Fish  <fnf@specifix.com>

	* gdb.texinfo (Symbols): Update descriptions of 'whatis' and
	'ptype' commands to reflect the fact that the only significant
	difference between them is that ptype prints the complete type
	description instead of just the name.

Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.313
diff -c -p -r1.313 gdb.texinfo
*** gdb.texinfo	10 Feb 2006 03:54:33 -0000	1.313
--- gdb.texinfo	17 Feb 2006 20:26:04 -0000
*************** it to find out the name of a variable or
*** 10364,10389 ****
  
  @kindex whatis
  @item whatis @var{expr}
! Print the data type of expression @var{expr}.  @var{expr} is not
! actually evaluated, and any side-effecting operations (such as
! assignments or function calls) inside it do not take place.
  @xref{Expressions, ,Expressions}.
  
- @item whatis
- Print the data type of @code{$}, the last value in the value history.
- 
  @kindex ptype
- @item ptype @var{typename}
- Print a description of data type @var{typename}.  @var{typename} may be
- the name of a type, or for C code it may have the form @samp{class
- @var{class-name}}, @samp{struct @var{struct-tag}}, @samp{union
- @var{union-tag}} or @samp{enum @var{enum-tag}}.
- 
  @item ptype @var{expr}
  @itemx ptype
! Print a description of the type of expression @var{expr}.  @code{ptype}
! differs from @code{whatis} by printing a detailed description, instead
! of just the name of the type.
  
  For example, for this variable declaration:
  
--- 10364,10388 ----
  
  @kindex whatis
  @item whatis @var{expr}
! @itemx whatis @var{typename}
! @itemx whatis
! Print the data type of expression @var{expr} or type @var{typename}.
! @var{expr} is not actually evaluated, and any side-effecting operations
! (such as assignments or function calls) inside it do not take place.
! @var{typename} may be the name of a type or typedef, or for C code it may
! have the form @samp{class @var{class-name}}, @samp{struct @var{struct-tag}},
! @samp{union @var{union-tag}} or @samp{enum @var{enum-tag}}.
! Without any arguments, print the data type of @code{$}, the last value
! in the value history.
  @xref{Expressions, ,Expressions}.
  
  @kindex ptype
  @item ptype @var{expr}
+ @itemx ptype @var{typename}
  @itemx ptype
! @code{ptype} accepts the same arguments as @code{whatis}, but prints a
! detailed description of the type, instead of just the name of the type.
! @xref{Expressions, ,Expressions}.
  
  For example, for this variable declaration:
  

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

[Eli Zaretskii]

> From: Fred Fish <fnf@diveadx.com>
> Date: Fri, 17 Feb 2006 15:31:27 -0500
> Cc: drow@false.org, jimb@red-bean.com, gdb-patches@sourceware.org,
>         fnf@specifix.com
> 
> On Friday 17 February 2006 04:15, Eli Zaretskii wrote:
> > Will the manual's description of the differences between these two
> > commands be still valid after this change?
> 
> Here is a patch for the doc change.

Thanks.  The doc patch is approved, but please take care of this minor
issue:

>   @kindex whatis
>   @item whatis @var{expr}
> ! @itemx whatis @var{typename}
> ! @itemx whatis
> ! Print the data type of expression @var{expr} or type @var{typename}.
> ! @var{expr} is not actually evaluated, and any side-effecting operations
> ! (such as assignments or function calls) inside it do not take place.
> ! @var{typename} may be the name of a type or typedef, or for C code it may
> ! have the form @samp{class @var{class-name}}, @samp{struct @var{struct-tag}},
> ! @samp{union @var{union-tag}} or @samp{enum @var{enum-tag}}.
> ! Without any arguments, print the data type of @code{$}, the last value
> ! in the value history.

Now that you've unified the descriptions, there's no need to have a
separate "@itemx whatis" without arguments, you can simply put the
argument in the other two @item's in [], to show that they are
optional.  I would even leave only one @item, and modify the
description slightly, like this:

  @item whatis [@var{arg}]
  Print the data type of expression @var{arg}, either an expression or
  a data type.  With no argument, print the data type of @code{$}, ...
  If @var{arg} is an expression, it is not actually evaluated, ...  If
  @var{arg} is a type name, it may be the name of a type or typedef, ...


>   @item ptype @var{expr}
> + @itemx ptype @var{typename}
>   @itemx ptype
> ! @code{ptype} accepts the same arguments as @code{whatis}, but prints a
> ! detailed description of the type, instead of just the name of the type.
> ! @xref{Expressions, ,Expressions}.

Same here.

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

[Daniel Jacobowitz]

On Thu, Feb 16, 2006 at 07:16:00PM -0500, Fred Fish wrote:
> On Tuesday 14 February 2006 09:10, Daniel Jacobowitz wrote:
> > This patch seems OK to me; but we really ought to fix up the comment
> > directly above this code that you're changing.
> 
> I've think it would be best to split work on this issue up into two parts
> 
> (1) Make ptype and whatis handle the same arguments.  Currently ptype
> will work on typedefs, but whatis does not.  This is the change that
> makes them both use whatis_exp and eliminates ptype_eval.
> 
> (2) Make ptype and whatis handle printing types specified in a given
> context using 'file'::type.  I have a fix that involves a fairly
> minor change to the parser and makes the patch you are commenting on
> obsolete.
> 
> Here is the patch for (1).  I believe we previously reached on consensus
> that this change was OK, so I'd like to get it checked in.  I added some
> testsuite support for testing how whatis behaves with typedef names.

I didn't see any followups to this except for the docs, but I've got no
objection, so it's just as well you've checked it in :-)


-- 
Daniel Jacobowitz
CodeSourcery

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

[Fred Fish]

On Thursday 16 February 2006 19:16, Fred Fish wrote:
> (2) Make ptype and whatis handle printing types specified in a given
> context using 'file'::type.  I have a fix that involves a fairly
> minor change to the parser and makes the patch you are commenting on
> obsolete.

OK, here is a patch. I'm not entirely happy with it but I'm not familiar
enough with parser generator input and output to see any obviously 
better way.

The basic problem is that it's easy to handle 'file'::variable.  The
existing code for this is:

  block :  block COLONCOLON name
                  { struct symbol *tem
                      = lookup_symbol (copy_name ($3), $1,
                                        VAR_DOMAIN, (int *) NULL,
                                        (struct symtab **) NULL);

What happens is that "name" is handled by a lookup_symbol call with
no context block specified, and then the above calls lookup_symbol
again with the context specified by $1 (block).

But for types, the parser generator input is:

  type    :       ptype
          |       block COLONCOLON ptype
                        { $$ = $3; }

Setting expression_context_block for the duration of parsing the
input expression was the only obvious way I saw to work around
not being able to call lookup_symbol again, with the right block.

I tried setting expression_context_block on the lexer code when it
returned BLOCKNAME or FILENAME and that broke some other stuff.

Any suggestions on better ways to handle this would be great.

-Fred

GDB ChangeLog:

 	2006-02-19  Fred Fish  <fnf@specifix.com>
	* c-exp.y (type): Recognize "block COLONCOLON ptype" as a type.
	(block): Set expression_context_block for lookup_symbol to use.

Testsuite ChangeLog:

	2006-02-19  Fred Fish  <fnf@specifix.com>
	* gdb.base/ptype.c (afoo): Add variable using foo typedef.
	* gdb.base/ptype1.c (afoo): Ditto.

	* gdb.base/ptype.exp: Add tests using 'file':: prefix
	to specify scope for variables and types.  Add tests for
	printing type of last value history entry.
	* gdb.base/whatis.exp: Ditto.
	
Index: c-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/c-exp.y,v
retrieving revision 1.33
diff -c -p -r1.33 c-exp.y
*** c-exp.y	14 Feb 2006 19:05:40 -0000	1.33
--- c-exp.y	20 Feb 2006 14:35:42 -0000
*************** exp     :       FALSEKEYWORD   
*** 556,562 ****
  block	:	BLOCKNAME
  			{
  			  if ($1.sym)
! 			    $$ = SYMBOL_BLOCK_VALUE ($1.sym);
  			  else
  			    error ("No file or function \"%s\".",
  				   copy_name ($1.stoken));
--- 556,565 ----
  block	:	BLOCKNAME
  			{
  			  if ($1.sym)
! 			    {
! 			      $$ = SYMBOL_BLOCK_VALUE ($1.sym);
! 			      expression_context_block = $$;
! 			    }
  			  else
  			    error ("No file or function \"%s\".",
  				   copy_name ($1.stoken));
*************** block	:	BLOCKNAME
*** 564,569 ****
--- 567,573 ----
  	|	FILENAME
  			{
  			  $$ = $1;
+ 			  expression_context_block = $$;
  			}
  	;
  
*************** block	:	block COLONCOLON name
*** 575,581 ****
  			  if (!tem || SYMBOL_CLASS (tem) != LOC_BLOCK)
  			    error ("No function \"%s\" in specified context.",
  				   copy_name ($3));
! 			  $$ = SYMBOL_BLOCK_VALUE (tem); }
  	;
  
  variable:	block COLONCOLON name
--- 579,586 ----
  			  if (!tem || SYMBOL_CLASS (tem) != LOC_BLOCK)
  			    error ("No function \"%s\" in specified context.",
  				   copy_name ($3));
! 			  $$ = SYMBOL_BLOCK_VALUE (tem);
! 			  expression_context_block = $$; }
  	;
  
  variable:	block COLONCOLON name
*************** func_mod:	'(' ')'
*** 799,804 ****
--- 804,811 ----
     is a pointer to member type.  Stroustrup loses again!  */
  
  type	:	ptype
+ 	|	block COLONCOLON ptype
+ 			{ $$ = $3; }
  	|	typebase COLONCOLON '*'
  			{ $$ = lookup_member_type (builtin_type (current_gdbarch)->builtin_int, $1); }
  	;
Index: testsuite/gdb.base/ptype.c
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/ptype.c,v
retrieving revision 1.4
diff -c -p -r1.4 ptype.c
*** testsuite/gdb.base/ptype.c	4 Jan 2006 14:46:17 -0000	1.4
--- testsuite/gdb.base/ptype.c	20 Feb 2006 14:45:25 -0000
*************** func_type v_func_type;
*** 260,265 ****
--- 260,266 ----
  /***********/
  
  typedef int foo;
+ static foo afoo = 2;
  
  foo intfoo (afoo)
  {
Index: testsuite/gdb.base/ptype.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/ptype.exp,v
retrieving revision 1.8
diff -c -p -r1.8 ptype.exp
*** testsuite/gdb.base/ptype.exp	4 Jan 2006 14:46:17 -0000	1.8
--- testsuite/gdb.base/ptype.exp	20 Feb 2006 14:45:49 -0000
*************** gdb_test "ptype foo" "type = int" "ptype
*** 594,599 ****
--- 594,613 ----
  gdb_test "list charfoo" ""
  gdb_test "ptype foo" "type = char" "ptype foo typedef after second list of charfoo"
  
+ # Test the 'file'::exp syntax for variables and types
+ 
+ gdb_test "ptype 'ptype.c'::afoo" "type = int" "ptype 'file'::symbol"
+ gdb_test "ptype 'ptype.c'::foo" "type = int" "ptype 'file'::typename"
+ gdb_test "ptype 'ptype1.c'::afoo" "type = char" "ptype 'file'::symbol"
+ gdb_test "ptype 'ptype1.c'::foo" "type = char" "ptype 'file'::typename"
+ 
+ # Test printing value history type
+ 
+ gdb_test "p (long)1" ""
+ gdb_test "ptype" "type = long" "ptype long value from value history"
+ gdb_test "p (short)1" ""
+ gdb_test "ptype" "type = short" "ptype short value from value history"
+ 
  # Test printing type of string constants and array constants, but
  # requires a running process.  These call malloc, and can take a long
  # time to execute over a slow serial link, so increase the timeout.
Index: testsuite/gdb.base/ptype1.c
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/ptype1.c,v
retrieving revision 1.1
diff -c -p -r1.1 ptype1.c
*** testsuite/gdb.base/ptype1.c	4 Jan 2006 14:46:17 -0000	1.1
--- testsuite/gdb.base/ptype1.c	20 Feb 2006 14:45:49 -0000
***************
*** 1,4 ****
--- 1,5 ----
  typedef char foo;
+ static foo afoo = 1;
  
  foo charfoo (afoo)
  {
Index: testsuite/gdb.base/whatis.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/whatis.exp,v
retrieving revision 1.7
diff -c -p -r1.7 whatis.exp
*** testsuite/gdb.base/whatis.exp	18 Feb 2006 20:01:17 -0000	1.7
--- testsuite/gdb.base/whatis.exp	20 Feb 2006 14:45:49 -0000
*************** gdb_test "whatis v_struct1" \
*** 273,300 ****
--- 273,324 ----
      "type = struct t_struct" \
      "whatis named structure"
  
+ gdb_test "whatis 'whatis.c'::v_struct1" \
+     "type = struct t_struct" \
+     "whatis named structure in explicit scope"
+ 
  gdb_test "whatis struct t_struct" \
      "type = struct t_struct" \
      "whatis named structure using type name"
  
+ gdb_test "whatis 'whatis.c'::struct t_struct" \
+     "type = struct t_struct" \
+     "whatis named structure using type name and explicit scope"
+ 
  gdb_test "whatis v_struct2" \
      "type = struct \{$unstruct\}" \
      "whatis unnamed structure"
  
+ gdb_test "whatis 'whatis.c'::v_struct2" \
+     "type = struct \{$unstruct\}" \
+     "whatis unnamed structure in explicit scope"
+ 
  
  # test whatis command with union types
  gdb_test "whatis v_union" \
      "type = union t_union" \
      "whatis named union"
  
+ gdb_test "whatis 'whatis.c'::v_union" \
+     "type = union t_union" \
+     "whatis named union in explicit scope"
+ 
  gdb_test "whatis union t_union" \
      "type = union t_union" \
      "whatis named union using type name"
  
+ gdb_test "whatis 'whatis.c'::union t_union" \
+     "type = union t_union" \
+     "whatis named union using type name and explicit scope"
+ 
  gdb_test "whatis v_union2" \
      "type = union \{$ununion\}" \
      "whatis unnamed union"
  
+ gdb_test "whatis 'whatis.c'::v_union2" \
+     "type = union \{$ununion\}" \
+     "whatis unnamed union in explicit scope"
+ 
  
  # HP-UX: HP aCC compiler w/ +objdebug option detects language as
  # c++, so we need the 'void' pattern here.
*************** gdb_test "whatis char_addr" \
*** 421,426 ****
--- 445,465 ----
      "type = char \\*" \
      "whatis using typedef type name"
  
+ gdb_test "whatis 'whatis.c'::char_addr" \
+     "type = char \\*" \
+     "whatis using typedef type name and explicit scope"
+ 
  gdb_test "whatis a_char_addr" \
      "type = char_addr" \
      "whatis applied to variable defined by typedef"
+ 
+ gdb_test "whatis 'whatis.c'::a_char_addr" \
+     "type = char_addr" \
+     "whatis applied to variable defined by typedef in explicit scope"
+ 
+ # Test printing value history type
+ 
+ gdb_test "p (long)1" ""
+ gdb_test "whatis" "type = long" "whatis long value from value history"
+ gdb_test "p (short)1" ""
+ gdb_test "whatis" "type = short" "whatis short value from value history"

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

[Daniel Jacobowitz]

On Mon, Feb 20, 2006 at 10:46:08AM -0500, Fred Fish wrote:
> OK, here is a patch. I'm not entirely happy with it but I'm not familiar
> enough with parser generator input and output to see any obviously 
> better way.
> 
> The basic problem is that it's easy to handle 'file'::variable.  The
> existing code for this is:
> 
>   block :  block COLONCOLON name
>                   { struct symbol *tem
>                       = lookup_symbol (copy_name ($3), $1,
>                                         VAR_DOMAIN, (int *) NULL,
>                                         (struct symtab **) NULL);
> 
> What happens is that "name" is handled by a lookup_symbol call with
> no context block specified, and then the above calls lookup_symbol
> again with the context specified by $1 (block).
> 
> But for types, the parser generator input is:
> 
>   type    :       ptype
>           |       block COLONCOLON ptype
>                         { $$ = $3; }
> 
> Setting expression_context_block for the duration of parsing the
> input expression was the only obvious way I saw to work around
> not being able to call lookup_symbol again, with the right block.
> 
> I tried setting expression_context_block on the lexer code when it
> returned BLOCKNAME or FILENAME and that broke some other stuff.
> 
> Any suggestions on better ways to handle this would be great.

Yuck.  In general futzing with global variables in a parser is bad
news.  And here's another good hint that this isn't happening in the
right place:

  type  :       ptype         
+       |       block COLONCOLON ptype                              
+                       { $$ = $3; }                      

but ptype : typebase, and typebase : INT_KEYWORD.  So this will allow
"ptype var.c:int".  I don't think that's a great idea (especially since
we won't use the debug info to look up "int" in that case anyway so we
still won't detect a mismatch).

The problem you're having is that the lexer looks up symbols without
knowing their context.  I think you're going to have some fragile
failure modes with things that are types in one file and not in
another, which it would be nice to support if we could.  The fact
that we try to differentiate between these two in the lexer is
a bit problematic.

One easy way to improve here would be to just look up the symbol
again.  But that still relies on the lexer having decided this
was a typename.

I'm not sure what to suggest.  Really this parser needs some more
thorough love and care.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Fred Fish]

On Monday 20 February 2006 11:23, Daniel Jacobowitz wrote:
> Yuck.  In general futzing with global variables in a parser is bad
> news.  And here's another good hint that this isn't happening in the
> right place:

OK.  Lets forget the c-exp.y part of the patch.

I think it would probably be a good idea to put in the testsuite
changes, pending a better fix...

With the attached patch, I get the new PASS's:

  PASS: gdb.base/ptype.exp: ptype 'file'::symbol
  PASS: gdb.base/ptype.exp: ptype 'file'::symbol
  PASS: gdb.base/ptype.exp: p (long)1
  PASS: gdb.base/ptype.exp: ptype long value from value history
  PASS: gdb.base/ptype.exp: p (short)1
  PASS: gdb.base/ptype.exp: ptype short value from value history
  PASS: gdb.base/whatis.exp: whatis named structure in explicit scope
  PASS: gdb.base/whatis.exp: whatis unnamed structure in explicit scope
  PASS: gdb.base/whatis.exp: whatis named union in explicit scope
  PASS: gdb.base/whatis.exp: whatis unnamed union in explicit scope
  PASS: gdb.base/whatis.exp: whatis applied to variable defined by typedef in explicit scope
  PASS: gdb.base/whatis.exp: p (long)1
  PASS: gdb.base/whatis.exp: whatis long value from value history
  PASS: gdb.base/whatis.exp: p (short)1
  PASS: gdb.base/whatis.exp: whatis short value from value history

and the (expected) failures:

  FAIL: gdb.base/ptype.exp: ptype 'file'::typename
  FAIL: gdb.base/ptype.exp: ptype 'file'::typename
  FAIL: gdb.base/whatis.exp: whatis named structure using type name and explicit scope
  FAIL: gdb.base/whatis.exp: whatis named union using type name and explicit scope
  FAIL: gdb.base/whatis.exp: whatis using typedef type name and explicit scope

-Fred

============================================================================

2006-05-17  Fred Fish  <fnf@specifix.com>

	* gdb.base/ptype.c (afoo): Add variable using foo typedef.
	* gdb.base/ptype1.c (afoo): Ditto.

	* gdb.base/ptype.exp: Add tests using 'file':: prefix
	to specify scope for variables and types.  Add tests for
	printing type of last value history entry.
	* gdb.base/whatis.exp: Ditto.

Index: gdb.base/ptype.c
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/testsuite/gdb.base/ptype.c,v
retrieving revision 1.1.1.2
diff -c -p -r1.1.1.2 ptype.c
*** gdb.base/ptype.c	8 Jan 2006 20:37:18 -0000	1.1.1.2
--- gdb.base/ptype.c	17 May 2006 18:53:28 -0000
*************** func_type v_func_type;
*** 260,265 ****
--- 260,266 ----
  /***********/
  
  typedef int foo;
+ static foo afoo = 2;
  
  foo intfoo (afoo)
  {
Index: gdb.base/ptype.exp
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/testsuite/gdb.base/ptype.exp,v
retrieving revision 1.1.1.2
diff -c -p -r1.1.1.2 ptype.exp
*** gdb.base/ptype.exp	8 Jan 2006 20:37:19 -0000	1.1.1.2
--- gdb.base/ptype.exp	17 May 2006 18:53:28 -0000
*************** gdb_test "ptype foo" "type = int" "ptype
*** 594,599 ****
--- 594,613 ----
  gdb_test "list charfoo" ""
  gdb_test "ptype foo" "type = char" "ptype foo typedef after second list of charfoo"
  
+ # Test the 'file'::exp syntax for variables and types
+ 
+ gdb_test "ptype 'ptype.c'::afoo" "type = int" "ptype 'file'::symbol"
+ gdb_test "ptype 'ptype.c'::foo" "type = int" "ptype 'file'::typename"
+ gdb_test "ptype 'ptype1.c'::afoo" "type = char" "ptype 'file'::symbol"
+ gdb_test "ptype 'ptype1.c'::foo" "type = char" "ptype 'file'::typename"
+ 
+ # Test printing value history type
+ 
+ gdb_test "p (long)1" ""
+ gdb_test "ptype" "type = long" "ptype long value from value history"
+ gdb_test "p (short)1" ""
+ gdb_test "ptype" "type = short" "ptype short value from value history"
+ 
  # Test printing type of string constants and array constants, but
  # requires a running process.  These call malloc, and can take a long
  # time to execute over a slow serial link, so increase the timeout.
Index: gdb.base/ptype1.c
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/testsuite/gdb.base/ptype1.c,v
retrieving revision 1.1.1.1
diff -c -p -r1.1.1.1 ptype1.c
*** gdb.base/ptype1.c	8 Jan 2006 20:37:18 -0000	1.1.1.1
--- gdb.base/ptype1.c	17 May 2006 18:53:28 -0000
***************
*** 1,4 ****
--- 1,5 ----
  typedef char foo;
+ static foo afoo = 1;
  
  foo charfoo (afoo)
  {
Index: gdb.base/whatis.exp
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/testsuite/gdb.base/whatis.exp,v
retrieving revision 1.1.1.2
diff -c -p -r1.1.1.2 whatis.exp
*** gdb.base/whatis.exp	18 Feb 2006 21:07:16 -0000	1.1.1.2
--- gdb.base/whatis.exp	17 May 2006 18:53:28 -0000
*************** gdb_test "whatis v_struct1" \
*** 273,300 ****
--- 273,324 ----
      "type = struct t_struct" \
      "whatis named structure"
  
+ gdb_test "whatis 'whatis.c'::v_struct1" \
+     "type = struct t_struct" \
+     "whatis named structure in explicit scope"
+ 
  gdb_test "whatis struct t_struct" \
      "type = struct t_struct" \
      "whatis named structure using type name"
  
+ gdb_test "whatis 'whatis.c'::struct t_struct" \
+     "type = struct t_struct" \
+     "whatis named structure using type name and explicit scope"
+ 
  gdb_test "whatis v_struct2" \
      "type = struct \{$unstruct\}" \
      "whatis unnamed structure"
  
+ gdb_test "whatis 'whatis.c'::v_struct2" \
+     "type = struct \{$unstruct\}" \
+     "whatis unnamed structure in explicit scope"
+ 
  
  # test whatis command with union types
  gdb_test "whatis v_union" \
      "type = union t_union" \
      "whatis named union"
  
+ gdb_test "whatis 'whatis.c'::v_union" \
+     "type = union t_union" \
+     "whatis named union in explicit scope"
+ 
  gdb_test "whatis union t_union" \
      "type = union t_union" \
      "whatis named union using type name"
  
+ gdb_test "whatis 'whatis.c'::union t_union" \
+     "type = union t_union" \
+     "whatis named union using type name and explicit scope"
+ 
  gdb_test "whatis v_union2" \
      "type = union \{$ununion\}" \
      "whatis unnamed union"
  
+ gdb_test "whatis 'whatis.c'::v_union2" \
+     "type = union \{$ununion\}" \
+     "whatis unnamed union in explicit scope"
+ 
  
  # HP-UX: HP aCC compiler w/ +objdebug option detects language as
  # c++, so we need the 'void' pattern here.
*************** gdb_test "whatis char_addr" \
*** 421,426 ****
--- 445,465 ----
      "type = char \\*" \
      "whatis using typedef type name"
  
+ gdb_test "whatis 'whatis.c'::char_addr" \
+     "type = char \\*" \
+     "whatis using typedef type name and explicit scope"
+ 
  gdb_test "whatis a_char_addr" \
      "type = char_addr" \
      "whatis applied to variable defined by typedef"
+ 
+ gdb_test "whatis 'whatis.c'::a_char_addr" \
+     "type = char_addr" \
+     "whatis applied to variable defined by typedef in explicit scope"
+ 
+ # Test printing value history type
+ 
+ gdb_test "p (long)1" ""
+ gdb_test "whatis" "type = long" "whatis long value from value history"
+ gdb_test "p (short)1" ""
+ gdb_test "whatis" "type = short" "whatis short value from value history"