FYI: [python/Ada] gdb.lookup_type fails to looking primitive type

FYI: [python/Ada] gdb.lookup_type fails to looking primitive type

[Joel Brobecker]

The following change...

    commit 1994afbf19892c9e614a034fbf1a5233e9addce3
    Date:   Tue Dec 23 07:55:39 2014 -0800
    Subject: Look up primitive types as symbols.

... caused the following regression:

    % gdb
    (gdb) set lang ada
    (gdb) python print gdb.lookup_type('character')
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
    gdb.error: No type named character.
    Error while executing Python code.

This is because the language_lookup_primitive_type_as_symbol call
was moved to the la_lookup_symbol_nonlocal hook. A couple of
implementations have been upated accordingly, but the Ada version
has not. This patch fixes this omission.

gdb/ChangeLog:

        * ada-lang.c (ada_lookup_symbol_nonlocal): If name not found
        in static block, then try searching for primitive types.

gdb/testsuite/ChangeLog:

        * gdb.python/py-lkup_type.exp: New file.

Tested on x86_64-linux, no regression.  It's getting late, here,
so I will push tomorrow, as I'd like to have the fix before we
branch.

---
 gdb/ada-lang.c                            | 33 ++++++++++++++++-
 gdb/testsuite/gdb.python/py-lkup_type.exp | 59 +++++++++++++++++++++++++++++++
 2 files changed, 91 insertions(+), 1 deletion(-)
 create mode 100644 gdb/testsuite/gdb.python/py-lkup_type.exp

diff --git a/gdb/ada-lang.c b/gdb/ada-lang.c
index 71c3b3a..ec06693 100644
--- a/gdb/ada-lang.c
+++ b/gdb/ada-lang.c
@@ -5598,7 +5598,38 @@ ada_lookup_symbol_nonlocal (const struct language_defn *langdef,
                             const struct block *block,
                             const domain_enum domain)
 {
-  return ada_lookup_symbol (name, block_static_block (block), domain, NULL);
+  struct symbol *sym;
+
+  sym = ada_lookup_symbol (name, block_static_block (block), domain, NULL);
+  if (sym != NULL)
+    return sym;
+
+  /* If we haven't found a match at this point, try the primitive
+     types.  In other languages, this search is performed before
+     searching for global symbols in order to short-circuit that
+     global-symbol search if it happens that the name corresponds
+     to a primitive type.  But we cannot do the same in Ada, because
+     it is perfectly legitimate for a program to declare a type which
+     has the same name as a standard type.  If looking up a type in
+     that situation, we have traditionally ignored the primitive type
+     in favor of user-defined types.  This is why, unlike most other
+     languages, we search the primitive types this late and only after
+     having searched the global symbols without success.  */
+
+  if (domain == VAR_DOMAIN)
+    {
+      struct gdbarch *gdbarch;
+
+      if (block == NULL)
+	gdbarch = target_gdbarch ();
+      else
+	gdbarch = block_gdbarch (block);
+      sym = language_lookup_primitive_type_as_symbol (langdef, gdbarch, name);
+      if (sym != NULL)
+	return sym;
+    }
+
+  return NULL;
 }
 
 
diff --git a/gdb/testsuite/gdb.python/py-lkup_type.exp b/gdb/testsuite/gdb.python/py-lkup_type.exp
new file mode 100644
index 0000000..d8fb9e7
--- /dev/null
+++ b/gdb/testsuite/gdb.python/py-lkup_type.exp
@@ -0,0 +1,59 @@
+# Copyright (C) 2015 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# This file is part of the GDB testsuite.  It tests the mechanism
+# of exposing types to Python.
+
+load_lib gdb-python.exp
+
+# Note that the purpose of this testcase is to test the behavior
+# of gdb.lookup_type searching for the primitive types internally
+# created by each language since GDB.  So, we must start GDB without
+# loading any symbol in.
+
+gdb_exit
+gdb_start
+gdb_reinitialize_dir $srcdir/$subdir
+
+# Skip all tests if Python scripting is not enabled.
+if { [skip_python_tests] } { continue }
+
+proc test_lookup_type { lang type_name } {
+    gdb_test_no_output "set language ${lang}"
+    gdb_test_no_output "python gdb.lookup_type('${type_name}')" \
+        "lookup type ${type_name} using language ${lang}"
+}
+
+test_lookup_type "ada" "character"
+
+test_lookup_type "c" "char"
+
+test_lookup_type "d" "ucent"
+
+test_lookup_type "fortran" "character"
+
+test_lookup_type "go" "int32"
+
+test_lookup_type "java" "byte"
+
+test_lookup_type "modula-2" "CARDINAL"
+
+test_lookup_type "opencl" "ushort"
+
+test_lookup_type "objective-c" "char"
+
+test_lookup_type "opencl" "ushort"
+
+test_lookup_type "pascal" "char"
-- 
1.9.1

Re: FYI: [python/Ada] gdb.lookup_type fails to looking primitive type

[Doug Evans]

On Mon, Jan 12, 2015 at 9:26 AM, Joel Brobecker <brobecker@adacore.com> wrote:
> The following change...
>
>     commit 1994afbf19892c9e614a034fbf1a5233e9addce3
>     Date:   Tue Dec 23 07:55:39 2014 -0800
>     Subject: Look up primitive types as symbols.
>
> ... caused the following regression:
>
>     % gdb
>     (gdb) set lang ada
>     (gdb) python print gdb.lookup_type('character')
>     Traceback (most recent call last):
>       File "<string>", line 1, in <module>
>     gdb.error: No type named character.
>     Error while executing Python code.
>
> This is because the language_lookup_primitive_type_as_symbol call
> was moved to the la_lookup_symbol_nonlocal hook. A couple of
> implementations have been upated accordingly, but the Ada version
> has not. This patch fixes this omission.
>
> gdb/ChangeLog:
>
>         * ada-lang.c (ada_lookup_symbol_nonlocal): If name not found
>         in static block, then try searching for primitive types.
>
> gdb/testsuite/ChangeLog:
>
>         * gdb.python/py-lkup_type.exp: New file.
>
> Tested on x86_64-linux, no regression.  It's getting late, here,
> so I will push tomorrow, as I'd like to have the fix before we
> branch.

Awesome, thanks.

Nit: py-lkup-tupe.exp instead of py-lkup_type.exp?
Or even py-lookup-type.exp.

Plus one more comment below.

> diff --git a/gdb/testsuite/gdb.python/py-lkup_type.exp b/gdb/testsuite/gdb.python/py-lkup_type.exp
> new file mode 100644
> index 0000000..d8fb9e7
> --- /dev/null
> +++ b/gdb/testsuite/gdb.python/py-lkup_type.exp
> @@ -0,0 +1,59 @@
> +# Copyright (C) 2015 Free Software Foundation, Inc.
> +
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 3 of the License, or
> +# (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program.  If not, see <http://www.gnu.org/licenses/>.
> +
> +# This file is part of the GDB testsuite.  It tests the mechanism
> +# of exposing types to Python.
> +
> +load_lib gdb-python.exp
> +
> +# Note that the purpose of this testcase is to test the behavior
> +# of gdb.lookup_type searching for the primitive types internally
> +# created by each language since GDB.  So, we must start GDB without
> +# loading any symbol in.
> +
> +gdb_exit
> +gdb_start
> +gdb_reinitialize_dir $srcdir/$subdir
> +
> +# Skip all tests if Python scripting is not enabled.
> +if { [skip_python_tests] } { continue }
> +
> +proc test_lookup_type { lang type_name } {
> +    gdb_test_no_output "set language ${lang}"
> +    gdb_test_no_output "python gdb.lookup_type('${type_name}')" \
> +        "lookup type ${type_name} using language ${lang}"
> +}

I wouldn't have expected gdb_test_no_output to work here
for python.lookup_type, though I can see that it does.
This is no different than "python 1+1": it doesn't print anything either.
[I wonder if we can fix that without having to add a knob.  Would anything
break if we started printing the result here? Possibly I guess.]

It's ok to leave as is, but you might want to add a clarifying comment.
Maybe something like

> +    gdb_test_no_output "set language ${lang}"
> +    # gdb discards python results, so what we're checking for here is the
> +    # presence of an error message.
> +    gdb_test_no_output "python gdb.lookup_type('${type_name}')" \
> +        "lookup type ${type_name} using language ${lang}"

> +
> +test_lookup_type "ada" "character"
> +
> +test_lookup_type "c" "char"
> +
> +test_lookup_type "d" "ucent"
> +
> +test_lookup_type "fortran" "character"
> +
> +test_lookup_type "go" "int32"
> +
> +test_lookup_type "java" "byte"
> +
> +test_lookup_type "modula-2" "CARDINAL"
> +
> +test_lookup_type "opencl" "ushort"
> +
> +test_lookup_type "objective-c" "char"
> +
> +test_lookup_type "opencl" "ushort"
> +
> +test_lookup_type "pascal" "char"
> --
> 1.9.1
>

Re: FYI: [python/Ada] gdb.lookup_type fails to looking primitive type

[Joel Brobecker]

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

> > gdb/ChangeLog:
> >
> >         * ada-lang.c (ada_lookup_symbol_nonlocal): If name not found
> >         in static block, then try searching for primitive types.
> >
> > gdb/testsuite/ChangeLog:
> >
> >         * gdb.python/py-lkup_type.exp: New file.
> >
> > Tested on x86_64-linux, no regression.  It's getting late, here,
> > so I will push tomorrow, as I'd like to have the fix before we
> > branch.
> 
> Awesome, thanks.

You are welcome.

> Nit: py-lkup-tupe.exp instead of py-lkup_type.exp?
> Or even py-lookup-type.exp.

OK, I changed it to py-lookup-type.exp.

> > +proc test_lookup_type { lang type_name } {
> > +    gdb_test_no_output "set language ${lang}"
> > +    gdb_test_no_output "python gdb.lookup_type('${type_name}')" \
> > +        "lookup type ${type_name} using language ${lang}"
> > +}
> 
> I wouldn't have expected gdb_test_no_output to work here
> for python.lookup_type, though I can see that it does.
> This is no different than "python 1+1": it doesn't print anything either.

And I actually believe that this is the expected behavior of a python
"script", even if the "script" is passed on the command line. I am
guessing that you are thinking of the case where you are inside the
interactive interpreter, in which case, yes, we expect it to print
the returned value each time. But this is not a test where we use
the interactive interpreter here, hence I would not expect any output.
If I wanted some output, I'd have used "print".

As a result, a "clarifying" comment would have actually confused
things more, IMO, and so I elected to not add one.

Attached is what I ended up checking in:

gdb/ChangeLog:

        * ada-lang.c (ada_lookup_symbol_nonlocal): If name not found
        in static block, then try searching for primitive types.

gdb/testsuite/ChangeLog:

        * gdb.python/py-lookup-type.exp: New file.

Thank you,
-- 
Joel

[-- Attachment #2: 0001-python-Ada-gdb.lookup_type-fails-to-looking-primitiv.patch --]
[-- Type: text/x-diff, Size: 6011 bytes --]

From 04dccad086aa9974fb66f8b5d1c1fb32d5a6ae0e Mon Sep 17 00:00:00 2001
From: Joel Brobecker <brobecker@adacore.com>
Date: Mon, 12 Jan 2015 15:46:34 +0400
Subject: [PATCH] [python/Ada] gdb.lookup_type fails to looking primitive type

The following change...

    commit 1994afbf19892c9e614a034fbf1a5233e9addce3
    Date:   Tue Dec 23 07:55:39 2014 -0800
    Subject: Look up primitive types as symbols.

... caused the following regression:

    % gdb
    (gdb) set lang ada
    (gdb) python print gdb.lookup_type('character')
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
    gdb.error: No type named character.
    Error while executing Python code.

This is because the language_lookup_primitive_type_as_symbol call
was moved to the la_lookup_symbol_nonlocal hook. A couple of
implementations have been upated accordingly, but the Ada version
has not. This patch fixes this omission.

gdb/ChangeLog:

        * ada-lang.c (ada_lookup_symbol_nonlocal): If name not found
        in static block, then try searching for primitive types.

gdb/testsuite/ChangeLog:

        * gdb.python/py-lookup-type.exp: New file.
---
 gdb/ChangeLog                               |  5 +++
 gdb/ada-lang.c                              | 33 +++++++++++++++-
 gdb/testsuite/ChangeLog                     |  4 ++
 gdb/testsuite/gdb.python/py-lookup-type.exp | 59 +++++++++++++++++++++++++++++
 4 files changed, 100 insertions(+), 1 deletion(-)
 create mode 100644 gdb/testsuite/gdb.python/py-lookup-type.exp

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index acbea15..6610b77 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,8 @@
+2015-01-13  Joel Brobecker  <brobecker@adacore.com>
+
+	* ada-lang.c (ada_lookup_symbol_nonlocal): If name not found
+	in static block, then try searching for primitive types.
+
 2015-01-12  Patrick Palka  <patrick@parcs.ath.cx>
 
 	* top.h (gdb_add_history): Declare.
diff --git a/gdb/ada-lang.c b/gdb/ada-lang.c
index 71c3b3a..ec06693 100644
--- a/gdb/ada-lang.c
+++ b/gdb/ada-lang.c
@@ -5598,7 +5598,38 @@ ada_lookup_symbol_nonlocal (const struct language_defn *langdef,
                             const struct block *block,
                             const domain_enum domain)
 {
-  return ada_lookup_symbol (name, block_static_block (block), domain, NULL);
+  struct symbol *sym;
+
+  sym = ada_lookup_symbol (name, block_static_block (block), domain, NULL);
+  if (sym != NULL)
+    return sym;
+
+  /* If we haven't found a match at this point, try the primitive
+     types.  In other languages, this search is performed before
+     searching for global symbols in order to short-circuit that
+     global-symbol search if it happens that the name corresponds
+     to a primitive type.  But we cannot do the same in Ada, because
+     it is perfectly legitimate for a program to declare a type which
+     has the same name as a standard type.  If looking up a type in
+     that situation, we have traditionally ignored the primitive type
+     in favor of user-defined types.  This is why, unlike most other
+     languages, we search the primitive types this late and only after
+     having searched the global symbols without success.  */
+
+  if (domain == VAR_DOMAIN)
+    {
+      struct gdbarch *gdbarch;
+
+      if (block == NULL)
+	gdbarch = target_gdbarch ();
+      else
+	gdbarch = block_gdbarch (block);
+      sym = language_lookup_primitive_type_as_symbol (langdef, gdbarch, name);
+      if (sym != NULL)
+	return sym;
+    }
+
+  return NULL;
 }
 
 
diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog
index db1f521..868339c 100644
--- a/gdb/testsuite/ChangeLog
+++ b/gdb/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2015-01-13  Joel Brobecker  <brobecker@adacore.com>
+
+	* gdb.python/py-lookup-type.exp: New file.
+
 2015-01-12  Pedro Alves  <palves@redhat.com>
 
 	* gdb.python/py-prompt.exp: When the board can't spawn for attach,
diff --git a/gdb/testsuite/gdb.python/py-lookup-type.exp b/gdb/testsuite/gdb.python/py-lookup-type.exp
new file mode 100644
index 0000000..d8fb9e7
--- /dev/null
+++ b/gdb/testsuite/gdb.python/py-lookup-type.exp
@@ -0,0 +1,59 @@
+# Copyright (C) 2015 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# This file is part of the GDB testsuite.  It tests the mechanism
+# of exposing types to Python.
+
+load_lib gdb-python.exp
+
+# Note that the purpose of this testcase is to test the behavior
+# of gdb.lookup_type searching for the primitive types internally
+# created by each language since GDB.  So, we must start GDB without
+# loading any symbol in.
+
+gdb_exit
+gdb_start
+gdb_reinitialize_dir $srcdir/$subdir
+
+# Skip all tests if Python scripting is not enabled.
+if { [skip_python_tests] } { continue }
+
+proc test_lookup_type { lang type_name } {
+    gdb_test_no_output "set language ${lang}"
+    gdb_test_no_output "python gdb.lookup_type('${type_name}')" \
+        "lookup type ${type_name} using language ${lang}"
+}
+
+test_lookup_type "ada" "character"
+
+test_lookup_type "c" "char"
+
+test_lookup_type "d" "ucent"
+
+test_lookup_type "fortran" "character"
+
+test_lookup_type "go" "int32"
+
+test_lookup_type "java" "byte"
+
+test_lookup_type "modula-2" "CARDINAL"
+
+test_lookup_type "opencl" "ushort"
+
+test_lookup_type "objective-c" "char"
+
+test_lookup_type "opencl" "ushort"
+
+test_lookup_type "pascal" "char"
-- 
1.9.1

Re: FYI: [python/Ada] gdb.lookup_type fails to looking primitive type

[Doug Evans]

On Tue, Jan 13, 2015 at 1:44 AM, Joel Brobecker <brobecker@adacore.com> wrote:
> ...
>> > +proc test_lookup_type { lang type_name } {
>> > +    gdb_test_no_output "set language ${lang}"
>> > +    gdb_test_no_output "python gdb.lookup_type('${type_name}')" \
>> > +        "lookup type ${type_name} using language ${lang}"
>> > +}
>>
>> I wouldn't have expected gdb_test_no_output to work here
>> for python.lookup_type, though I can see that it does.
>> This is no different than "python 1+1": it doesn't print anything either.
>
> And I actually believe that this is the expected behavior of a python
> "script", even if the "script" is passed on the command line. I am
> guessing that you are thinking of the case where you are inside the
> interactive interpreter, in which case, yes, we expect it to print
> the returned value each time. But this is not a test where we use
> the interactive interpreter here, hence I would not expect any output.
> If I wanted some output, I'd have used "print".
>
> As a result, a "clarifying" comment would have actually confused
> things more, IMO, and so I elected to not add one.

Alas I was confused without it. :-)

> Attached is what I ended up checking in:
>
> gdb/ChangeLog:
>
>         * ada-lang.c (ada_lookup_symbol_nonlocal): If name not found
>         in static block, then try searching for primitive types.
>
> gdb/testsuite/ChangeLog:
>
>         * gdb.python/py-lookup-type.exp: New file.

Not that I'm expecting anyone to go back and change things,
but maybe for future reference it'd be better to print the result
and record the expected output, instead of expecting no output.
Performing a lookup action, and then expecting no output,
is just too confusing to me.

Re: FYI: [python/Ada] gdb.lookup_type fails to looking primitive type

[Joel Brobecker]

> > gdb/testsuite/ChangeLog:
> >
> >         * gdb.python/py-lookup-type.exp: New file.
> 
> Not that I'm expecting anyone to go back and change things,
> but maybe for future reference it'd be better to print the result
> and record the expected output, instead of expecting no output.
> Performing a lookup action, and then expecting no output,
> is just too confusing to me.

The only issue I have with that is that I'd like to do something
whose behavior is defined. Looking at the GDB manual, I can't see
anything said about what to expect when converting a gdb.Type to
a string... If we clarify that, I have no problem adding the extra
"print" in the test.

-- 
Joel

Re: FYI: [python/Ada] gdb.lookup_type fails to looking primitive type

[Joel Brobecker]

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

> > Not that I'm expecting anyone to go back and change things,
> > but maybe for future reference it'd be better to print the result
> > and record the expected output, instead of expecting no output.
> > Performing a lookup action, and then expecting no output,
> > is just too confusing to me.
> 
> The only issue I have with that is that I'd like to do something
> whose behavior is defined. Looking at the GDB manual, I can't see
> anything said about what to expect when converting a gdb.Type to
> a string... If we clarify that, I have no problem adding the extra
> "print" in the test.

I tried looking into the code as to what the semantics of printing
the gdb.Type object should be, and couldn't figure it out. It seems
to be printing the type name, but I'm not sure why. So, instead of
waiting for a clarification that may never come, I propose the
following.

gdb/ChangeLog:

        * gdb.python/py-lookup-type.exp (test_lookup_type): Change
        the second test to print the name attribute of value
        returned by the call to gdb.lookup_type, and adjust
        the expected output accordingly.

Tested on x86_64-linux.

Does this change answer your concerns?

-- 
Joel

[-- Attachment #2: 0001-check-gdb.lookup_type-return-value-in-gdb.python-py-.patch --]
[-- Type: text/x-diff, Size: 1303 bytes --]

From eea862a6a45741d97bca981b7c8356782e02c0a3 Mon Sep 17 00:00:00 2001
From: Joel Brobecker <brobecker@adacore.com>
Date: Wed, 21 Jan 2015 10:29:09 +0100
Subject: [PATCH] check gdb.lookup_type return value in
 gdb.python/py-lookup-type.exp

This further improves this testcase to check the output of
our calls to gdb.lookup_type.

gdb/ChangeLog:

        * gdb.python/py-lookup-type.exp (test_lookup_type): Change
        the second test to print the name attribute of value
        returned by the call to gdb.lookup_type, and adjust
        the expected output accordingly.
---
 gdb/testsuite/gdb.python/py-lookup-type.exp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.python/py-lookup-type.exp b/gdb/testsuite/gdb.python/py-lookup-type.exp
index d8fb9e7..46d6fc6 100644
--- a/gdb/testsuite/gdb.python/py-lookup-type.exp
+++ b/gdb/testsuite/gdb.python/py-lookup-type.exp
@@ -32,7 +32,8 @@ if { [skip_python_tests] } { continue }
 
 proc test_lookup_type { lang type_name } {
     gdb_test_no_output "set language ${lang}"
-    gdb_test_no_output "python gdb.lookup_type('${type_name}')" \
+    gdb_test "python print(gdb.lookup_type('${type_name}').name)" \
+        "${type_name}" \
         "lookup type ${type_name} using language ${lang}"
 }
 
-- 
1.9.1

Re: FYI: [python/Ada] gdb.lookup_type fails to looking primitive type

[Doug Evans]

On Wed, Jan 21, 2015 at 1:44 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> > Not that I'm expecting anyone to go back and change things,
>> > but maybe for future reference it'd be better to print the result
>> > and record the expected output, instead of expecting no output.
>> > Performing a lookup action, and then expecting no output,
>> > is just too confusing to me.
>>
>> The only issue I have with that is that I'd like to do something
>> whose behavior is defined. Looking at the GDB manual, I can't see
>> anything said about what to expect when converting a gdb.Type to
>> a string... If we clarify that, I have no problem adding the extra
>> "print" in the test.
>
> I tried looking into the code as to what the semantics of printing
> the gdb.Type object should be, and couldn't figure it out. It seems
> to be printing the type name, but I'm not sure why. So, instead of
> waiting for a clarification that may never come, I propose the
> following.

Ah, I didn't know you were waiting on me.
I think printing the type name is just what was chosen at the time.
That choice is fine by me fwiw.

> gdb/ChangeLog:
>
>         * gdb.python/py-lookup-type.exp (test_lookup_type): Change
>         the second test to print the name attribute of value
>         returned by the call to gdb.lookup_type, and adjust
>         the expected output accordingly.
>
> Tested on x86_64-linux.
>
> Does this change answer your concerns?

There was no need to address anything, but thanks.
I was just making a suggestion for the next time.
[And I mean "suggestion" literally. 1/2 :-)]

The patch is fine by me.
Thanks again.

pushed: FYI: [python/Ada] gdb.lookup_type fails to looking primitive type

[Joel Brobecker]

> Ah, I didn't know you were waiting on me.
> I think printing the type name is just what was chosen at the time.
> That choice is fine by me fwiw.
> 
> > gdb/ChangeLog:
> >
> >         * gdb.python/py-lookup-type.exp (test_lookup_type): Change
> >         the second test to print the name attribute of value
> >         returned by the call to gdb.lookup_type, and adjust
> >         the expected output accordingly.
> >
> > Tested on x86_64-linux.
> >
> > Does this change answer your concerns?
> 
> There was no need to address anything, but thanks.
> I was just making a suggestion for the next time.
> [And I mean "suggestion" literally. 1/2 :-)]
> 
> The patch is fine by me.
> Thanks again.

Thanks for the feedback. I pushed the patch to master.

-- 
Joel