From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Subject: [PATCH 1/2] [gdb/macro] Ignore in-file macro definition with 0 line complaint for clang
Date: Fri, 17 May 2024 12:47:03 +0200 [thread overview]
Message-ID: <20240517104704.3477-1-tdevries@suse.de> (raw)
When showing complaints for the exec of test-case
gdb.dwarf2/clang-cli-macro.exp, we get:
...
$ gdb -q -batch -iex "set complaints 5" clang-cli-macro -ex "p main"
During symbol reading: \
debug info gives in-file macro definition with zero line 0: ONE 1
$1 = {int ()} 0x4004b7 <main>
...
The readelf output for the .debug_macro section looks like:
...
Contents of the .debug_macro section:
Offset: 0
Version: 5
Offset size: 4
Offset into .debug_line: 0xe3
DW_MACRO_start_file - lineno: 0 filenum: 1
DW_MACRO_define - lineno : 1 macro : TWO 2
DW_MACRO_end_file
DW_MACRO_define - lineno : 0 macro : ONE 1
...
The complaint is that the DW_MACRO_define for ONE both:
- has lineno 0, so it's predefined or specified on the command line, and
- occurs after the first DW_MACRO_start_file.
In commit e7e7469e7a3 ("gdb: Fix issue with Clang CLI macros") we've added a
workaround to accept this style of .debug_macro section, and
gdb.dwarf2/clang-cli-macro.exp is the test-case for the workaround.
Given that we've added the workaround, it doesn't make sense to complain.
The warning is produced using the following condition in
dwarf_decode_macro_bytes:
...
if ((line == 0 && !at_commandline)
|| (line != 0 && at_commandline))
...
using the variable at_commandline which is initially 1, and set to 0 when
encountering the first DW_MACRO_start_file.
The value of this variable doesn't make sense in the context of a clang-style
.debug_macro section.
We could try to fix this by changing the value of the variable to fit with the
clang-style .debug_macro section, but I don't think it's worth the effort.
Simply fix this by for a clang producer opting out of all complaints in the
function that use the at_commandline variable in the condition.
Tested on x86_64-linux.
---
gdb/dwarf2/macro.c | 10 ++++++----
gdb/testsuite/gdb.dwarf2/clang-cli-macro.exp | 6 ++++++
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/gdb/dwarf2/macro.c b/gdb/dwarf2/macro.c
index a511d0a3b44..66a40e88d3a 100644
--- a/gdb/dwarf2/macro.c
+++ b/gdb/dwarf2/macro.c
@@ -546,8 +546,9 @@ dwarf_decode_macro_bytes (dwarf2_per_objfile *per_objfile,
line, body);
break;
}
- if ((line == 0 && !at_commandline)
- || (line != 0 && at_commandline))
+ if (((line == 0 && !at_commandline)
+ || (line != 0 && at_commandline))
+ && !producer_is_clang (cu))
complaint (_("debug info gives %s macro %s with %s line %d: %s"),
at_commandline ? _("command-line") : _("in-file"),
is_define ? _("definition") : _("undefinition"),
@@ -648,8 +649,9 @@ dwarf_decode_macro_bytes (dwarf2_per_objfile *per_objfile,
file = read_unsigned_leb128 (abfd, mac_ptr, &bytes_read);
mac_ptr += bytes_read;
- if ((line == 0 && !at_commandline)
- || (line != 0 && at_commandline))
+ if (((line == 0 && !at_commandline)
+ || (line != 0 && at_commandline))
+ && !producer_is_clang (cu))
complaint (_("debug info gives source %d included "
"from %s at %s line %d"),
file, at_commandline ? _("command-line") : _("file"),
diff --git a/gdb/testsuite/gdb.dwarf2/clang-cli-macro.exp b/gdb/testsuite/gdb.dwarf2/clang-cli-macro.exp
index eafb75ad8d9..fdeaaff5afd 100644
--- a/gdb/testsuite/gdb.dwarf2/clang-cli-macro.exp
+++ b/gdb/testsuite/gdb.dwarf2/clang-cli-macro.exp
@@ -85,6 +85,12 @@ if {[prepare_for_testing "failed to prepare" $testfile [list $srcfile $asm_file]
return
}
+set re_result "[string_to_regexp $]$decimal = \[^\r\n\]+"
+
+with_complaints 5 {
+ gdb_test "print main" ^$re_result "no complaints"
+}
+
if {![runto_main]} {
return
}
base-commit: 44fc9616c2e74396395f60c9a601317e4c4c4733
--
2.35.3
next reply other threads:[~2024-05-17 10:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-17 10:47 Tom de Vries [this message]
2024-05-17 10:47 ` [PATCH 2/2] [gdb/macro] Ignore malformed macro definition " Tom de Vries
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=20240517104704.3477-1-tdevries@suse.de \
--to=tdevries@suse.de \
--cc=gdb-patches@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).