public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: "Zaric, Zoran (Zare)" <Zoran.Zaric@amd.com>
To: "Kempke, Nils-Christian" <nils-christian.kempke@intel.com>,
	Simon Marchi <simark@simark.ca>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Cc: "tom@tromey.com" <tom@tromey.com>
Subject: RE: [PATCH 3/4] gdb, typeprint: fix pointer/reference typeprint for icc/ifort
Date: Tue, 27 Sep 2022 09:14:44 +0000	[thread overview]
Message-ID: <BN9PR12MB50653AC3FA2F8EF680A2106AF8559@BN9PR12MB5065.namprd12.prod.outlook.com> (raw)
In-Reply-To: <CY4PR1101MB20711EE9EE370A97EFEFA21CB8529@CY4PR1101MB2071.namprd11.prod.outlook.com>

[AMD Official Use Only - General]

Hi Kempke and Simon,

If you don't mind I would like to step in for a second on comment on your last question:

> 
> Yes, so this part in the DWARF is also where I am quite unsure about what
> the DWARF actually allows.  I agree that the DWARF icc/ifort emit is a bit
> weird.
> And I also prefer the way gfortran/ifx emit Fortran/C pointers..
> And I agree that the original thought behind DW_AT_data_location was
> different.
> 
> My main confusion is here:
> 
> looking at the example D.2.1, if I follow your argument, why would we then
> use the address of arrayvar to evaluate the bounds? Would
> DW_OP_push_object_address within the DW_TAG_subrange_type then not
> also need to push the subrange's address (and indicate some offset to the
> address of its base type, the DW_TAG_subrange_type)?
> 
> The example uses the address of 'arrayvar'.  I find the example a bit
> confusing and I do not clearly understand what the 'current object' is.  As we
> only have a chain of DWARF DIE's I tend to assume that the innermost
> variable in the chain is meant.
> Everything else seems not well defined, e.g., why assume that the
> DW_TAG_array_type changes the 'current object' but the
> DW_TAG_subrange_type does not?
> 

The key difference here is that the DW_TAG_reference_type is a "standalone" type and there is always an object or a member (a physical location description) behind it while the DW_TAG_subrange_type is a by definition tied to a "standalone" array types. Unfortunately, it is not really meaningful to have an object of a DW_TAG_subrange_type so the type is more there to allow factorizing of the debug information.

In the case of DW_TAG_reference_type, there is always an object that is the reference to something and if you dereference it, you get another object that the original object referenced, which is a very different case then the DW_TAG_subrange_type and the array type that references it.

That being said, I don't believe that there is anywhere in DWARF stating that if there is an actual object of a DW_TAG_subrange_type type that the DW_OP_push_object_address operation (in any of the attributes of that type) should not use it, it just that the way how this type is defined doesn't really allow you to have a separate object of that type.

At the end of the day, the definition of DW_OP_push_object_address operation just states that the operation pushes the address of the object currently being evaluated, It even states that it could be a component of an object, but it still has to be something tangible (a real location).

I hope this clarifies things a bit for you.

Regards,
Zoran

  reply	other threads:[~2022-09-27  9:14 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-20  7:26 [PATCH 0/4] Dynamic properties of pointers Nils-Christian Kempke
2022-09-20  7:26 ` [PATCH 1/4] gdb, testsuite: handle icc and icpc deprecated remarks Nils-Christian Kempke
2022-09-26 14:32   ` Simon Marchi
2022-09-20  7:26 ` [PATCH 2/4] gdb/types: Resolve pointer types dynamically Nils-Christian Kempke
2022-09-26 15:33   ` Simon Marchi
2022-09-29 12:39     ` Kempke, Nils-Christian
2022-09-20  7:26 ` [PATCH 3/4] gdb, typeprint: fix pointer/reference typeprint for icc/ifort Nils-Christian Kempke
2022-09-26 16:02   ` Simon Marchi
2022-09-26 17:18     ` Kempke, Nils-Christian
2022-09-27  9:14       ` Zaric, Zoran (Zare) [this message]
2022-09-27 12:48         ` Simon Marchi
2022-09-20  7:26 ` [PATCH 4/4] gdb/fortran: Fix sizeof intrinsic for Fortran Nils-Christian Kempke
2022-09-26 17:06   ` Simon Marchi
2022-09-26 17:22     ` Kempke, Nils-Christian
2022-09-26 17:24     ` Kempke, Nils-Christian

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=BN9PR12MB50653AC3FA2F8EF680A2106AF8559@BN9PR12MB5065.namprd12.prod.outlook.com \
    --to=zoran.zaric@amd.com \
    --cc=gdb-patches@sourceware.org \
    --cc=nils-christian.kempke@intel.com \
    --cc=simark@simark.ca \
    --cc=tom@tromey.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).