public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "vries at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/115272] New: [debug] complex type is hard to related back to base type Date: Wed, 29 May 2024 09:49:42 +0000 [thread overview] Message-ID: <bug-115272-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115272 Bug ID: 115272 Summary: [debug] complex type is hard to related back to base type Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- Consider test.c: ... $ cat test.c __complex__ float cf; __complex__ double cd; __complex__ long double cld; ... compiled using an arm-linux-gnueabihf target compiler: ... $ gcc test.c -g -c ... The three types are represented like this: ... <1><2e>: Abbrev Number: 2 (DW_TAG_base_type) <2f> DW_AT_byte_size : 8 <30> DW_AT_encoding : 3 (complex float) <30> DW_AT_name : complex float <1><44>: Abbrev Number: 2 (DW_TAG_base_type) <45> DW_AT_byte_size : 16 <46> DW_AT_encoding : 3 (complex float) <46> DW_AT_name : complex double <1><5b>: Abbrev Number: 2 (DW_TAG_base_type) <5c> DW_AT_byte_size : 16 <5d> DW_AT_encoding : 3 (complex float) <5d> DW_AT_name : (indirect string, offset: 0): complex long double ... Note that the sizes of complex double and complex long double are the same. When printing the type of the real component in gdb, we get: ... $ gdb -q -batch test.o \ -ex 'p $_creal(cf)' -ex 'ptype $' \ -ex 'p $_creal(cd)' -ex 'ptype $' \ -ex 'p $_creal(cld)' -ex 'ptype $' $1 = 0 type = float $2 = 0 type = double $3 = 0 type = double ... We'd prefer to get "long double" for the real component of complex long double. I submitted a fix for gdb that achieves this here ( https://sourceware.org/pipermail/gdb-patches/2024-May/209415.html ). The fix involves grepping for "long" in the name of the complex type, which is hacky and fragile, but it's the best we can do with the current state of debug info. If gcc would emit a DW_AT_type pointing to the component type, this could be solved cleanly and unambiguously. [ Note: this was also discussed as a solution to PR93988, but a different solution was chosen there ( https://dwarfstd.org/issues/210218.2.html ). ] As things stand, a DW_TAG_base_type is not allowed to have a DW_AT_type, but we could add this as an extension.
next reply other threads:[~2024-05-29 9:49 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-05-29 9:49 vries at gcc dot gnu.org [this message] 2024-05-29 11:18 ` [Bug debug/115272] " rguenth at gcc dot gnu.org 2024-05-29 11:19 ` rguenth at gcc dot gnu.org 2024-05-29 12:03 ` vries at gcc dot gnu.org 2024-05-29 12:08 ` vries at gcc dot gnu.org 2024-06-19 15:38 ` vries at gcc dot gnu.org
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-115272-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.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).