[Bug gdb/30105] New: ptype of internal convenience functions is broken

[Bug gdb/30105] New: ptype of internal convenience functions is broken

[pedro at palves dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=30105

            Bug ID: 30105
           Summary: ptype of internal convenience functions is broken
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: pedro at palves dot net
  Target Milestone: ---

Currently, we get:

 (gdb) ptype $_isvoid
 type = <internal function>type not handled in c_type_print_varspec_prefix()

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30105] ptype of internal convenience functions is broken

[pedro at palves dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=30105

Pedro Alves <pedro at palves dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at sourceware dot org   |pedro at palves dot net

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30105] ptype of internal convenience functions is broken

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30105

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Pedro Alves <palves@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a975d4e6bcf84d3676cbc47b1c9456cf4c3a32a6

commit a975d4e6bcf84d3676cbc47b1c9456cf4c3a32a6
Author: Pedro Alves <pedro@palves.net>
Date:   Fri Feb 10 11:32:35 2023 +0000

    Fix "ptype INTERNAL_FUNC" (PR gdb/30105)

    Currently, looking at the type of an internal function, like below,
    hits an odd error:

     (gdb) ptype $_isvoid
     type = <internal function>type not handled in
c_type_print_varspec_prefix()

    That is an error thrown from
    c-typeprint.c:c_type_print_varspec_prefix, where it reads:

        ...
        case TYPE_CODE_DECFLOAT:
        case TYPE_CODE_FIXED_POINT:
          /* These types need no prefix.  They are listed here so that
             gcc -Wall will reveal any types that haven't been handled.  */
          break;
        default:
          error (_("type not handled in c_type_print_varspec_prefix()"));
          break;

    Internal function types have type code TYPE_CODE_INTERNAL_FUNCTION,
    which is not explicitly handled by that switch.

    That comment quoted above says that gcc -Wall will reveal any types
    that haven't been handled, but that's not actually true, at least with
    modern GCCs.  You would need to enable -Wswitch-enum for that, which
    we don't.  If I do enable that warning, then I see that we're missing
    handling for the following type codes:

       TYPE_CODE_INTERNAL_FUNCTION,
       TYPE_CODE_MODULE,
       TYPE_CODE_NAMELIST,
       TYPE_CODE_XMETHOD

    TYPE_CODE_MODULE and TYPE_CODE_NAMELIST and Fortran-specific, so it'd
    be a little weird to handle them here.

    I tried to reach this code with TYPE_CODE_XMETHOD, but couldn't figure
    out how to.  ptype on an xmethod isn't treated specially, it just
    complains that the method doesn't exist.  I've extended the
    gdb.python/py-xmethods.exp testcase to make sure of that.

    My thinking is that whatever type code we add next, the most likely
    scenario is that it won't need any special handling, so we'd just be
    adding another case to that "do nothing" list.  If we do need special
    casing for whatever type code, I think that tests added at the same
    time as the feature would uncover it anyhow.  If we do miss adding the
    special casing, then it still looks better to me to print the type
    somewhat incompletely than to error out and make it harder for users
    to debug whatever they need.  So I think that the best thing to do
    here is to just remove all those explicit "do nothing" cases, along
    with the error default case.

    After doing that, I decided to write a testcase that iterates over all
    supported languages doing "ptype INTERNAL_FUNC".  That revealed that
    Pascal has a similar problem, except the default case hits a
    gdb_assert instead of an error:

     (gdb) with language pascal -- ptype $_isvoid
     type =
     ../../src/gdb/p-typeprint.c:268: internal-error:
type_print_varspec_prefix: unexpected type
     A problem internal to GDB has been detected,
     further debugging may prove unreliable.

    That is fixed by this patch in the same way.

    You'll notice that the new testcase special-cases the Ada expected
    output:

            } elseif {$lang == "ada"} {
                gdb_test "ptype \$_isvoid" "<<internal function>>"
            } else {
                gdb_test "ptype \$_isvoid" "<internal function>"
            }

    That will be subject of the following patch.

    Approved-By: Andrew Burgess <aburgess@redhat.com>
    Change-Id: I81aec03523cceb338b5180a0b4c2e4ad26b4c4db
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30105

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30105] ptype of internal convenience functions is broken

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30105

--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Pedro Alves <palves@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=751495be92b2b319fb66ce4e12b562a0e27c15fe

commit 751495be92b2b319fb66ce4e12b562a0e27c15fe
Author: Pedro Alves <pedro@palves.net>
Date:   Fri Feb 10 11:55:00 2023 +0000

    Make "ptype INTERNAL_FUNCTION" in Ada print like other languages

    Currently, printing the type of an internal function in Ada shows
    double <>s, like:

     (gdb) with language ada -- ptype $_isvoid
     type = <<internal function>>

    while all other languages print it with a single <>, like:

     (gdb) with language c -- ptype $_isvoid
     type = <internal function>

    I don't think there's a reason that Ada needs to be different.  We
    currently print the double <>s because we take this path in
    ada_print_type:

        switch (type->code ())
          {
          default:
            gdb_printf (stream, "<");
            c_print_type (type, "", stream, show, level, language_ada, flags);
            gdb_printf (stream, ">");
            break;

    ... and the type's name already has the <>s.

    Fix this by simply adding an early check for
    TYPE_CODE_INTERNAL_FUNCTION.

    Approved-By: Andrew Burgess <aburgess@redhat.com>
    Approved-By: Tom Tromey <tom@tromey.com>
    Change-Id: Ic2b6527b9240a367471431023f6e27e6daed5501
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30105

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30105] ptype of internal convenience functions is broken

[pedro at palves dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=30105

Pedro Alves <pedro at palves dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.1

--- Comment #3 from Pedro Alves <pedro at palves dot net> ---
Fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30105] ptype of internal convenience functions is broken

[pedro at palves dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=30105

Pedro Alves <pedro at palves dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #4 from Pedro Alves <pedro at palves dot net> ---
Really, it's fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.