Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Tom de Vries (Code Review)" <gerrit@gnutoolchain-gerrit.osci.io>
To: gdb-patches@sourceware.org
Cc: Joel Brobecker <brobecker@adacore.com>,
	Tom Tromey <tromey@sourceware.org>,
	Luis Machado <luis.machado@linaro.org>,
	Andrew Burgess <andrew.burgess@embecosm.com>
Subject: [review v3] [gdb/symtab] Prefer var def over decl
Date: Thu, 07 Nov 2019 14:27:00 -0000	[thread overview]
Message-ID: <20191107142711.C284925B28@gnutoolchain-gerrit.osci.io> (raw)
In-Reply-To: <gerrit.1571043046000.Id92326cb8ef9903b121ef9e320658eb565d0f5a9@gnutoolchain-gerrit.osci.io>

Tom de Vries has posted comments on this change.

Change URL: https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/29
......................................................................


Patch Set 3:

> Patch Set 3:
> 
> Thank you for doing this.
> 
> The patch itself seems perfectly fine to me.  I appreciated the comment
> and the test case -- those help a lot.
> 
> However, I wonder why gdb is even making a symbol for a declaration in the
> first place.  For some other kinds of declarations, gdb doesn't bother, so
> I was wondering if it's possible to simply ignore them in general.

In general, there's a use of adding variable declarations to the symbol table. Say we have a declaration of a variable in one file, and the definition in another.  If the file with the definition is build without debug info, but the file with the declaration with debug info, we can combine the debuginfo of the declaration and the minimal symbol info of the definition to print the value of the variable using the proper type.

But in the case of this PR, the size of the declaration is zero, and that currently means that this information composition doesn't work. That could be fixed by using the size of the symbol from the minimal symbol info (that's PR24989).

As for the question whether we can ignore the declaration, I've tried this approach (let's call it ignore.patch).

Ignore.patch:
...
diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
index 0a7a0334202..381bd45e805 100644
--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -21830,6 +21830,10 @@ new_symbol (struct die_info *die, struct type *type, struct dwarf2_cu *cu,
              else if (attr2 && (DW_UNSND (attr2) != 0)
                       && dwarf2_attr (die, DW_AT_type, cu) != NULL)
                {
+                 if (die->tag == DW_TAG_variable && die_is_declaration (die, cu)
+                     && TYPE_LENGTH (SYMBOL_TYPE (sym)) == 0)
+                     suppress_add = 1;
+
                  /* A variable with DW_AT_external is never static, but it
                     may be block-scoped.  */
                  list_to_add
...

It passes regression testing, and fixes the original test-case for this PR (PR24971).

Ignore.patch does not fix the test-case added in the current patch set, but that one would have to be adapted for this fix (this fix works when type size is zero, and that's not the case for that test-case).

Also, ignore.patch fixes the test-case of the spinoff PR24985.

OTOH, if we go with ignore.patch, it may have to be reverted again in order to trigger the (currently non-existing) fix for PR24989.

So AFAIU:
- if we fix this PR using ignore.patch and then revert it in order to fix PR24972, the test-case for this PR is handled by looking up the symbol size in the minimal symbol info
- if we fix this PR using the currently proposed patch set, and then fix PR24972, the test-case for this PR is still handled by finding the definition instead of the declaration.


-- 
Gerrit-Project: binutils-gdb
Gerrit-Branch: master
Gerrit-Change-Id: Id92326cb8ef9903b121ef9e320658eb565d0f5a9
Gerrit-Change-Number: 29
Gerrit-PatchSet: 3
Gerrit-Owner: Tom de Vries <tdevries@suse.de>
Gerrit-Reviewer: Andrew Burgess <andrew.burgess@embecosm.com>
Gerrit-Reviewer: Luis Machado <luis.machado@linaro.org>
Gerrit-Reviewer: Tom de Vries <tdevries@suse.de>
Gerrit-CC: Joel Brobecker <brobecker@adacore.com>
Gerrit-CC: Tom Tromey <tromey@sourceware.org>
Gerrit-Comment-Date: Thu, 07 Nov 2019 14:27:11 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
Gerrit-MessageType: comment


  parent reply	other threads:[~2019-11-07 14:27 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <gerrit.1571043046000.Id92326cb8ef9903b121ef9e320658eb565d0f5a9@gnutoolchain-gerrit.osci.io>
2019-10-14 16:35 ` Change in binutils-gdb[master]: " Tom de Vries (Code Review)
2019-10-18 13:31 ` [review] " Luis Machado (Code Review)
2019-10-18 16:44 ` Tom de Vries (Code Review)
2019-10-23 16:27 ` [review v3] " Tom de Vries (Code Review)
2019-10-23 16:29 ` Tom de Vries (Code Review)
2019-10-31 15:50 ` Tom Tromey (Code Review)
2019-11-04  1:11 ` Joel Brobecker (Code Review)
2019-11-07 14:27 ` Tom de Vries (Code Review) [this message]
2019-11-07 15:30 ` Tom de Vries (Code Review)
2019-11-11 16:45 ` Joel Brobecker (Code Review)
2019-11-14 16:38 ` Tom de Vries (Code Review)
2019-11-21 13:34 ` Tom Tromey (Code Review)
2019-11-22 10:24 ` Tom de Vries (Code Review)
2019-11-22 11:02 ` Tom de Vries (Code Review)
2019-11-22 12:17 ` [review v4] " Tom de Vries (Code Review)
2019-11-22 12:19 ` Tom de Vries (Code Review)
2019-12-05 20:29 ` Tom Tromey (Code Review)
2019-12-06 17:53 ` [pushed] " Sourceware to Gerrit sync (Code Review)
2019-12-06 17:53 ` Sourceware to Gerrit sync (Code Review)
2019-12-09  6:29 ` [review v5] " Tom de Vries (Code Review)

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=20191107142711.C284925B28@gnutoolchain-gerrit.osci.io \
    --to=gerrit@gnutoolchain-gerrit.osci.io \
    --cc=andrew.burgess@embecosm.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=gnutoolchain-gerrit@osci.io \
    --cc=luis.machado@linaro.org \
    --cc=tromey@sourceware.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