From: Indu Bhagat <indu.bhagat@oracle.com>
To: gcc-patches@gcc.gnu.org
Cc: david.faust@oracle.com, Indu Bhagat <indu.bhagat@oracle.com>
Subject: [PATCH 1/2] ctf: fix PR debug/112878
Date: Wed, 10 Apr 2024 11:25:10 -0700 [thread overview]
Message-ID: <20240410182511.1528093-2-indu.bhagat@oracle.com> (raw)
In-Reply-To: <20240410182511.1528093-1-indu.bhagat@oracle.com>
PR debug/112878: ICE: in ctf_add_slice, at ctfc.cc:499 with _BitInt > 255 in a struct and -gctf1
The CTF generation in GCC does not have a mechanism to roll-back an
already added type. In this testcase presented in the PR, we hit a
representation limit in CTF slices (for a member of a struct) and ICE,
after the type for struct (CTF_K_STRUCT) has already been added to the
container.
To exit gracefully instead, we now check for both the offset and size of
the bitfield to be explicitly <= 255. If the check fails, we emit the
member with type CTF_K_UNKNOWN. Note that, the value 255 stems from the
existing binutils libctf checks which were motivated to guard against
malformed inputs.
Although it is not accurate to say that this is a CTF representation
limit, mark the code with TBD_CTF_REPRESENTATION_LIMIT for now so that
this can be taken care of with the next format version bump, when
libctf's checks for the slice data can be lifted as well.
gcc/ChangeLog:
PR debug/112878
* dwarf2ctf.cc (gen_ctf_sou_type): Check for conditions before
call to ctf_add_slice. Use CTF_K_UNKNOWN type if fail.
gcc/testsuite/ChangeLog:
PR debug/112878
* gcc.dg/debug/ctf/ctf-bitfields-5.c: New test.
---
gcc/dwarf2ctf.cc | 15 ++++++++++-----
.../gcc.dg/debug/ctf/ctf-bitfields-5.c | 17 +++++++++++++++++
2 files changed, 27 insertions(+), 5 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/debug/ctf/ctf-bitfields-5.c
diff --git a/gcc/dwarf2ctf.cc b/gcc/dwarf2ctf.cc
index 77d6bf89689..dc59569fe56 100644
--- a/gcc/dwarf2ctf.cc
+++ b/gcc/dwarf2ctf.cc
@@ -606,11 +606,16 @@ gen_ctf_sou_type (ctf_container_ref ctfc, dw_die_ref sou, uint32_t kind)
if (attr)
bitpos += AT_unsigned (attr);
- field_type_id = ctf_add_slice (ctfc, CTF_ADD_NONROOT,
- field_type_id,
- bitpos - field_location,
- bitsize,
- c);
+ /* This is not precisely a TBD_CTF_REPRESENTATION_LIMIT, but
+ surely something to look at for the next format version bump
+ for CTF. */
+ if (bitsize <= 255 && (bitpos - field_location) <= 255)
+ field_type_id = ctf_add_slice (ctfc, CTF_ADD_NONROOT,
+ field_type_id,
+ bitpos - field_location,
+ bitsize, c);
+ else
+ field_type_id = gen_ctf_unknown_type (ctfc);
}
/* Add the field type to the struct or union type. */
diff --git a/gcc/testsuite/gcc.dg/debug/ctf/ctf-bitfields-5.c b/gcc/testsuite/gcc.dg/debug/ctf/ctf-bitfields-5.c
new file mode 100644
index 00000000000..fee8228647c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/debug/ctf/ctf-bitfields-5.c
@@ -0,0 +1,17 @@
+/* Bitfield where the bit offset is > 255 is not allowed in CTF.
+
+ PR debug/112878.
+ This testcase is to ensure graceful handling. No slices are expected. */
+
+/* { dg-do compile { target bitint } } */
+/* { dg-options "-O0 -gctf -dA" } */
+
+/* No slices are expected, but a struct with one member is expected.
+ CTF_K_UNKNOWN is also expected. */
+/* { dg-final { scan-assembler-times "cts_type" 0 } } */
+/* { dg-final { scan-assembler-times "\[\t \]0x1a000001\[\t \]+\[^\n\]*ctt_info" 1 } } */
+/* { dg-final { scan-assembler-times "ascii \"unknown.0\"\[\t \]+\[^\n\]*ctf_string" 1 } } */
+
+struct {
+ _BitInt(282) a : 280;
+} b;
--
2.43.0
next prev parent reply other threads:[~2024-04-10 18:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-10 18:25 [PATCH 0/2] Fix PR debug/112878 and a BTF issue Indu Bhagat
2024-04-10 18:25 ` Indu Bhagat [this message]
2024-04-10 19:06 ` [PATCH 1/2] ctf: fix PR debug/112878 David Faust
2024-04-10 18:25 ` [PATCH 2/2] btf: do not skip members of data type with type id BTF_VOID_TYPEID Indu Bhagat
2024-04-10 19:18 ` David Faust
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=20240410182511.1528093-2-indu.bhagat@oracle.com \
--to=indu.bhagat@oracle.com \
--cc=david.faust@oracle.com \
--cc=gcc-patches@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: link
Be 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).