public inbox for
 help / color / mirror / Atom feed
From: Tom Tromey <>
To: Nils-Christian Kempke via Gdb-patches <>
Cc: Nils-Christian Kempke <>,
Subject: Re: [PATCH v2 3/4] gdb, typeprint: workaround icc/icpc/ifort pointer/reference DWARF
Date: Thu, 05 Jan 2023 12:46:30 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Nils-Christian Kempke via Gdb-patches's message of "Wed, 5 Oct 2022 22:40:38 +0200")

>>>>> Nils-Christian Kempke via Gdb-patches <> writes:

> Intel classic compilers (icc/icpc/ifort) for references/pointers
> to arrays generate DWARF that looks like

Thank you for the patch.

> +  if (!top_level && icc_pointer_or_reference_type (type))
> +    {
> +      /* Icc/ifort emit the DW_AT_associated for pointers and references.  To
> +	 not mark such types as dynamic further down, which would lead to
> +	 infinite resolution loops for, e.g., cyclic dynamic pointers, we
> +	 return here already.  */
> +      return 0;

I suspect this is not the best spot to do this kind of check.

> +bool
> +icc_pointer_or_reference_type (const struct type *type)
> +{
> +  return (type->code () == TYPE_CODE_PTR || type->code () == TYPE_CODE_REF)
> +	 && type->is_objfile_owned ()
> +	 && std::any_of (type->objfile_owner ()->compunits ().begin (),
> +			 type->objfile_owner ()->compunits ().end (),
> +			 [] (const compunit_symtab *cu)
> +			 {
> +			   return producer_is_icc (cu->producer (), nullptr,
> +						   nullptr);
> +			 });

And I really don't like this, because it's over-broad.  If an objfile
has objects from two different compilers, this code will erroneously

Instead, it seems to me that a better approach would be to recognize
the oddities in the DWARF reader, and then perhaps either introduce new
types or mark the type somehow for later processing.

If you search for "quirk" it the reader, you'll see other examples of
this technique.  E.g., the Rust compiler used to emit a custom format
for Rust enums, and the code in the DWARF reader converts these types
into the internal representation used in the rest of gdb.

I'm not sure if this can completely be done in your case or not, but I
think it would be better to try.  If it fails, adding a new flag to the
type would be better than searching all the objfile's compunits.


  reply	other threads:[~2023-01-05 19:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-05 20:40 [PATCH v2 0/4] Dynamic properties of pointers Nils-Christian Kempke
2022-10-05 20:40 ` [PATCH v2 1/4] gdb, testsuite: handle icc and icpc deprecated remarks Nils-Christian Kempke
2022-10-05 20:40 ` [PATCH v2 2/4] gdb/types: Resolve pointer types dynamically Nils-Christian Kempke
2023-01-05 19:35   ` Tom Tromey
2022-10-05 20:40 ` [PATCH v2 3/4] gdb, typeprint: workaround icc/icpc/ifort pointer/reference DWARF Nils-Christian Kempke
2023-01-05 19:46   ` Tom Tromey [this message]
2022-10-05 20:40 ` [PATCH v2 4/4] gdb/fortran: Fix sizeof intrinsic for Fortran Nils-Christian Kempke

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* 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).