diff options
author | Indu Bhagat <indu.bhagat@oracle.com> | 2024-04-10 17:27:52 -0700 |
---|---|---|
committer | Indu Bhagat <indu.bhagat@oracle.com> | 2024-04-10 17:31:27 -0700 |
commit | 5c869aa8a4538b218d9e59de6c96133971e7b965 (patch) | |
tree | 3d5a1db7672290f8de73502f1e44554b605242fe /gcc/cp/module.cc | |
parent | 0f3e76ee53a610a80e0fa032a252ed9d2505e6b7 (diff) | |
download | gcc-5c869aa8a4538b218d9e59de6c96133971e7b965.zip gcc-5c869aa8a4538b218d9e59de6c96133971e7b965.tar.gz gcc-5c869aa8a4538b218d9e59de6c96133971e7b965.tar.bz2 |
ctf: fix PR debug/112878
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.
Diffstat (limited to 'gcc/cp/module.cc')
0 files changed, 0 insertions, 0 deletions