From: David Faust <david.faust@oracle.com>
To: Indu Bhagat <indu.bhagat@oracle.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH 2/2] btf: do not skip members of data type with type id BTF_VOID_TYPEID
Date: Wed, 10 Apr 2024 12:18:53 -0700 [thread overview]
Message-ID: <f010ce89-5371-4930-9fca-f36c088994f6@oracle.com> (raw)
In-Reply-To: <20240410182511.1528093-3-indu.bhagat@oracle.com>
Hi Indu,
On 4/10/24 11:25, Indu Bhagat wrote:
> Testing the previous fix in gen_ctf_sou_type () reveals an issue in BTF
> generation, however: BTF emission was currently decrementing the vlen
> (indicating the number of members) to skip members of type CTF_K_UNKNOWN
> altogether, but still emitting the BTF for the corresponding member (in
> output_asm_btf_sou_fields ()).
>
> One can see malformed BTF by executing the newly added CTF testcase
> (gcc.dg/debug/ctf/ctf-bitfields-5.c) with -gbtf instead or even existing
> btf-struct-2.c without this patch.
>
> To fix the issue, it makes sense to rather _not_ skip members of data
> type of type id BTF_VOID_TYPEID.
Thank you for catching and fixing this.
FWIW, what to do in such cases for a struct with a member that has no
representation is undefined behavior in BTF. I certainly agree it's
better not to emit something malformed, and using 'void' is a good
choice. Better to know there was a member there that could not be
represented than to skip it altogether, and the total struct size
shall still be correct.
OK.
Thanks!
>
> gcc/ChangeLog:
> * btfout.cc (btf_asm_type): Do not skip emitting members of
> unknown type.
>
> gcc/testsuite/ChangeLog:
> * btf-bitfields-4.c: Update the vlen check.
> * btf-struct-2.c: Check that member named 'f' with void data
> type is emitted.
> ---
> gcc/btfout.cc | 5 -----
> gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-4.c | 6 +++---
> gcc/testsuite/gcc.dg/debug/btf/btf-struct-2.c | 9 +++++----
> 3 files changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/gcc/btfout.cc b/gcc/btfout.cc
> index 4a8ec4d1ff0..ab491f0297f 100644
> --- a/gcc/btfout.cc
> +++ b/gcc/btfout.cc
> @@ -820,11 +820,6 @@ btf_asm_type (ctf_container_ref ctfc, ctf_dtdef_ref dtd)
> /* Set kflag if this member is a representable bitfield. */
> if (btf_dmd_representable_bitfield_p (ctfc, dmd))
> btf_kflag = 1;
> -
> - /* Struct members that refer to unsupported types or bitfield formats
> - shall be skipped. These are marked during preprocessing. */
> - else if (!btf_emit_id_p (dmd->dmd_type))
> - btf_vlen -= 1;
> }
> }
>
> diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-4.c b/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-4.c
> index c00c8b3d87f..d4a6ef6a1eb 100644
> --- a/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-4.c
> +++ b/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-4.c
> @@ -6,14 +6,14 @@
> In this test, we construct a structure such that the bitfield will have
> an offset so large as to be unrepresentable in BTF. We expect that the
> resulting BTF will describe the rest of the structure, ignoring the
> - non-representable bitfield. */
> + non-representable bitfield by simply using void data type for the same. */
>
> /* { dg-do compile } */
> /* { dg-options "-O0 -gbtf -dA" } */
> /* { dg-require-effective-target size32plus } */
>
> -/* Struct with 3 members and no bitfield (kind_flag not set). */
> -/* { dg-final { scan-assembler-times "\[\t \]0x4000003\[\t \]+\[^\n\]*btt_info" 1 } } */
> +/* Struct with 4 members and no bitfield (kind_flag not set). */
> +/* { dg-final { scan-assembler-times "\[\t \]0x4000004\[\t \]+\[^\n\]*btt_info" 1 } } */
>
> struct bigly
> {
> diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-struct-2.c b/gcc/testsuite/gcc.dg/debug/btf/btf-struct-2.c
> index e9ff06883db..fa7231be75c 100644
> --- a/gcc/testsuite/gcc.dg/debug/btf/btf-struct-2.c
> +++ b/gcc/testsuite/gcc.dg/debug/btf/btf-struct-2.c
> @@ -2,14 +2,15 @@
> unsupported type.
>
> BTF does not support vector types (among other things). When
> - generating BTF for a struct (or union) type, members which refer to
> - unsupported types should be skipped. */
> + generating BTF for a struct (or union) type. Members which refer to
> + unsupported types should not be skipped, however. */
>
> /* { dg-do compile } */
> /* { dg-options "-O0 -gbtf -dA" } */
>
> -/* Expect a struct with only 2 members - 'f' should not be present. */
> -/* { dg-final { scan-assembler-times "\[\t \]0x4000002\[\t \]+\[^\n\]*btt_info" 1 } } */
> +/* Expect a struct with 3 members - 'f' is present but is of data type void. */
> +/* { dg-final { scan-assembler-times "\[\t \]0x4000003\[\t \]+\[^\n\]*btt_info" 1 } } */
> +/* { dg-final { scan-assembler-times " MEMBER 'f' idx=1\[\\r\\n\]+\[^\\r\\n\]*0\[\t \]+\[^\n\]*btm_type: void" 1 } } */
>
> struct with_float
> {
prev parent reply other threads:[~2024-04-10 19:20 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 ` [PATCH 1/2] ctf: fix PR debug/112878 Indu Bhagat
2024-04-10 19:06 ` 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 [this message]
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=f010ce89-5371-4930-9fca-f36c088994f6@oracle.com \
--to=david.faust@oracle.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=indu.bhagat@oracle.com \
/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).