public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug gdb/30105] ptype of internal convenience functions is broken Date: Wed, 15 Feb 2023 21:01:34 +0000 [thread overview] Message-ID: <bug-30105-4717-7EJO3caX3C@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-30105-4717@http.sourceware.org/bugzilla/> 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.
next prev parent reply other threads:[~2023-02-15 21:01 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-02-09 20:49 [Bug gdb/30105] New: " pedro at palves dot net 2023-02-10 12:24 ` [Bug gdb/30105] " pedro at palves dot net 2023-02-15 21:01 ` cvs-commit at gcc dot gnu.org [this message] 2023-02-15 21:01 ` cvs-commit at gcc dot gnu.org 2023-02-15 21:05 ` pedro at palves dot net 2023-02-15 21:06 ` pedro at palves dot net
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-30105-4717-7EJO3caX3C@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).