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