Message ID | 20230320163003.32960-1-simon.marchi@efficios.com |
---|---|
State | New |
Headers |
Return-Path: <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 10EF6385116B for <patchwork@sourceware.org>; Mon, 20 Mar 2023 16:30:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 10EF6385116B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1679329832; bh=Ut+74gJLXWl4mdt5rO8ewpso9LOT3Jw1DOc/7hiucuA=; h=To:Cc:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=Qt7m6hj8i4n1j/VDLliyN0e5cnWxvi2PcdUd4waswfmack5Ue2yzZ/mN6hAbu3idV sbI7bkKaRCtzJjup9H5scfY54ZDk0JLE+5UEA28Sja4hffd8jVgJz1WcajEp2Sy94/ bMtoHxE500GaghFjBJIlCKB250kHIfIbqRagQsrQ= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id C3CCA3858413 for <gdb-patches@sourceware.org>; Mon, 20 Mar 2023 16:30:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C3CCA3858413 Received: from smarchi-efficios.internal.efficios.com (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 2B7691E0D3; Mon, 20 Mar 2023 12:30:04 -0400 (EDT) To: gdb-patches@sourceware.org Cc: Simon Marchi <simon.marchi@efficios.com> Subject: [PATCH] gdb: make "maintenance info line-table" show relocated addresses again Date: Mon, 20 Mar 2023 12:30:03 -0400 Message-Id: <20230320163003.32960-1-simon.marchi@efficios.com> X-Mailer: git-send-email 2.40.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3497.2 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_NONE, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_SOFTFAIL, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list <gdb-patches.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=subscribe> From: Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> Reply-To: Simon Marchi <simon.marchi@efficios.com> Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
gdb: make "maintenance info line-table" show relocated addresses again
|
|
Commit Message
Simon Marchi
March 20, 2023, 4:30 p.m. UTC
Commit 1acc9dca423f ("Change linetables to be objfile-independent") changed "maintenance info line-table" to print unrelocated addresses instead of relocated. This breaks a few tests on systems where that matters. The ones I see are: Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/consecutive.exp ... FAIL: gdb.base/consecutive.exp: stopped at bp, 2nd instr (missing hex prefix) Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/async.exp ... FAIL: gdb.base/async.exp: stepi& FAIL: gdb.base/async.exp: nexti& FAIL: gdb.base/async.exp: finish& These tests run "maintenance info line-table" to record the address of some lines, and then use these addresses in expected patterns. For the time being, I suggest simply reverting the command to show relocated addresses. Change-Id: I59558f167e13e63421c9e0f2cad192e7c95c10cf --- gdb/symmisc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Comments
Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes: > Commit 1acc9dca423f ("Change linetables to be objfile-independent") > changed "maintenance info line-table" to print unrelocated addresses > instead of relocated. This breaks a few tests on systems where that > matters. The ones I see are: > > Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/consecutive.exp ... > FAIL: gdb.base/consecutive.exp: stopped at bp, 2nd instr (missing hex prefix) > Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/async.exp ... > FAIL: gdb.base/async.exp: stepi& > FAIL: gdb.base/async.exp: nexti& > FAIL: gdb.base/async.exp: finish& > > These tests run "maintenance info line-table" to record the address of > some lines, and then use these addresses in expected patterns. > > For the time being, I suggest simply reverting the command to show > relocated addresses. This makes sense to me. When I use 'maint info line-table' it's usually because I want to try and match up the line table with the code being executed, so having the relocated addresses would be far more useful. Reviewed-By: Andrew Burgess <aburgess@redhat.com> Thanks, Andrew > > Change-Id: I59558f167e13e63421c9e0f2cad192e7c95c10cf > --- > gdb/symmisc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gdb/symmisc.c b/gdb/symmisc.c > index 54dc570d282f..8296857d06c3 100644 > --- a/gdb/symmisc.c > +++ b/gdb/symmisc.c > @@ -996,7 +996,7 @@ maintenance_print_one_line_table (struct symtab *symtab, void *data) > else > uiout->field_string ("line", _("END")); > uiout->field_core_addr ("address", objfile->arch (), > - CORE_ADDR (item->raw_pc ())); > + item->pc (objfile)); > uiout->field_string ("is-stmt", item->is_stmt ? "Y" : ""); > uiout->field_string ("prologue-end", item->prologue_end ? "Y" : ""); > uiout->text ("\n"); > -- > 2.40.0
On 3/20/23 17:35, Andrew Burgess via Gdb-patches wrote: > Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes: > >> Commit 1acc9dca423f ("Change linetables to be objfile-independent") >> changed "maintenance info line-table" to print unrelocated addresses >> instead of relocated. This breaks a few tests on systems where that >> matters. The ones I see are: >> >> Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/consecutive.exp ... >> FAIL: gdb.base/consecutive.exp: stopped at bp, 2nd instr (missing hex prefix) >> Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/async.exp ... >> FAIL: gdb.base/async.exp: stepi& >> FAIL: gdb.base/async.exp: nexti& >> FAIL: gdb.base/async.exp: finish& >> >> These tests run "maintenance info line-table" to record the address of >> some lines, and then use these addresses in expected patterns. >> >> For the time being, I suggest simply reverting the command to show >> relocated addresses. > > This makes sense to me. When I use 'maint info line-table' it's usually > because I want to try and match up the line table with the code being > executed, so having the relocated addresses would be far more useful. > > Reviewed-By: Andrew Burgess <aburgess@redhat.com> What would you think about showing both, like this? (gdb) maintenance info line-table objfile: /home/simark/build/binutils-gdb/gdb/a.out ((struct objfile *) 0x614000007240) compunit_symtab: test.c ((struct compunit_symtab *) 0x621000123890) symtab: /home/simark/build/binutils-gdb/gdb/test.c ((struct symtab *) 0x621000123910) linetable: ((struct linetable *) 0x62100015fc20): INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END 0 6 0x0000555555555119 0x0000000000001119 Y 1 7 0x000055555555511d 0x000000000000111d Y 2 8 0x0000555555555123 0x0000000000001123 Y 3 END 0x0000555555555125 0x0000000000001125 Y I think it could be useful to match the unrelocated address with what you see in the DWARF info. If the objfile is not position-independent, or not relocated yet, the two columns show the same values. Simon
Simon Marchi <simark@simark.ca> writes: > On 3/20/23 17:35, Andrew Burgess via Gdb-patches wrote: >> Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes: >> >>> Commit 1acc9dca423f ("Change linetables to be objfile-independent") >>> changed "maintenance info line-table" to print unrelocated addresses >>> instead of relocated. This breaks a few tests on systems where that >>> matters. The ones I see are: >>> >>> Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/consecutive.exp ... >>> FAIL: gdb.base/consecutive.exp: stopped at bp, 2nd instr (missing hex prefix) >>> Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/async.exp ... >>> FAIL: gdb.base/async.exp: stepi& >>> FAIL: gdb.base/async.exp: nexti& >>> FAIL: gdb.base/async.exp: finish& >>> >>> These tests run "maintenance info line-table" to record the address of >>> some lines, and then use these addresses in expected patterns. >>> >>> For the time being, I suggest simply reverting the command to show >>> relocated addresses. >> >> This makes sense to me. When I use 'maint info line-table' it's usually >> because I want to try and match up the line table with the code being >> executed, so having the relocated addresses would be far more useful. >> >> Reviewed-By: Andrew Burgess <aburgess@redhat.com> > > What would you think about showing both, like this? > > (gdb) maintenance info line-table > objfile: /home/simark/build/binutils-gdb/gdb/a.out ((struct objfile *) 0x614000007240) > compunit_symtab: test.c ((struct compunit_symtab *) 0x621000123890) > symtab: /home/simark/build/binutils-gdb/gdb/test.c ((struct symtab *) 0x621000123910) > linetable: ((struct linetable *) 0x62100015fc20): > INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END > 0 6 0x0000555555555119 0x0000000000001119 Y > 1 7 0x000055555555511d 0x000000000000111d Y > 2 8 0x0000555555555123 0x0000000000001123 Y > 3 END 0x0000555555555125 0x0000000000001125 Y > > I think it could be useful to match the unrelocated address with what > you see in the DWARF info. If the objfile is not position-independent, > or not relocated yet, the two columns show the same values. I'm never going to complain about more information. Especially not in maintainer commands. Just wanted to make sure my use case was noted. Thanks, Andrew
> I'm never going to complain about more information. Especially not in > maintainer commands. > > Just wanted to make sure my use case was noted. Thanks, here's what I pushed. Simon From 904d9b02a185c9048cf17bf7295b89d7380cea3d Mon Sep 17 00:00:00 2001 From: Simon Marchi <simon.marchi@efficios.com> Date: Thu, 16 Mar 2023 16:30:34 -0400 Subject: [PATCH] gdb: make "maintenance info line-table" show relocated addresses again Commit 1acc9dca423f ("Change linetables to be objfile-independent") changed "maintenance info line-table" to print unrelocated addresses instead of relocated. This breaks a few tests on systems where that matters. The ones I see are: Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/consecutive.exp ... FAIL: gdb.base/consecutive.exp: stopped at bp, 2nd instr (missing hex prefix) Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/async.exp ... FAIL: gdb.base/async.exp: stepi& FAIL: gdb.base/async.exp: nexti& FAIL: gdb.base/async.exp: finish& These tests run "maintenance info line-table" to record the address of some lines, and then use these addresses in expected patterns. It therefore expects these addresses to match the runtime addresses, therefore the relocated addresses. Add back the relocated addresses, next to the unrelocated addresses, like so: INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END 0 6 0x0000555555555119 0x0000000000001119 Y 1 7 0x000055555555511d 0x000000000000111d Y 2 8 0x0000555555555123 0x0000000000001123 Y 3 END 0x0000555555555125 0x0000000000001125 Y The unrelocated addresses can always be useful trying to map this information with a DWARF info dump. Adjust the is_stmt_addresses proc in the testsuite to match the new output. Change-Id: I59558f167e13e63421c9e0f2cad192e7c95c10cf --- gdb/symmisc.c | 9 ++++++--- gdb/testsuite/lib/gdb.exp | 2 +- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/gdb/symmisc.c b/gdb/symmisc.c index 54dc570d282f..a09b541f1b39 100644 --- a/gdb/symmisc.c +++ b/gdb/symmisc.c @@ -976,10 +976,11 @@ maintenance_print_one_line_table (struct symtab *symtab, void *data) /* Leave space for 6 digits of index and line number. After that the tables will just not format as well. */ struct ui_out *uiout = current_uiout; - ui_out_emit_table table_emitter (uiout, 5, -1, "line-table"); + ui_out_emit_table table_emitter (uiout, 6, -1, "line-table"); uiout->table_header (6, ui_left, "index", _("INDEX")); uiout->table_header (6, ui_left, "line", _("LINE")); - uiout->table_header (18, ui_left, "address", _("ADDRESS")); + uiout->table_header (18, ui_left, "rel-address", _("REL-ADDRESS")); + uiout->table_header (18, ui_left, "unrel-address", _("UNREL-ADDRESS")); uiout->table_header (7, ui_left, "is-stmt", _("IS-STMT")); uiout->table_header (12, ui_left, "prologue-end", _("PROLOGUE-END")); uiout->table_body (); @@ -995,7 +996,9 @@ maintenance_print_one_line_table (struct symtab *symtab, void *data) uiout->field_signed ("line", item->line); else uiout->field_string ("line", _("END")); - uiout->field_core_addr ("address", objfile->arch (), + uiout->field_core_addr ("rel-address", objfile->arch (), + item->pc (objfile)); + uiout->field_core_addr ("unrel-address", objfile->arch (), CORE_ADDR (item->raw_pc ())); uiout->field_string ("is-stmt", item->is_stmt ? "Y" : ""); uiout->field_string ("prologue-end", item->prologue_end ? "Y" : ""); diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index 0a0ae697d1ee..6c2d7e1c74e5 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -8872,7 +8872,7 @@ proc is_stmt_addresses { file } { set is_stmt [list] gdb_test_multiple "maint info line-table $file" "" { - -re "\r\n$decimal\[ \t\]+$decimal\[ \t\]+($hex)\[ \t\]+Y\[^\r\n\]*" { + -re "\r\n$decimal\[ \t\]+$decimal\[ \t\]+($hex)\[ \t\]+$hex\[ \t\]+Y\[^\r\n\]*" { lappend is_stmt $expect_out(1,string) exp_continue } base-commit: bcefc6be9754d45fb9391993e6daaf01a68d9bd5
On 3/22/23 02:35, Simon Marchi via Gdb-patches wrote: > >> I'm never going to complain about more information. Especially not in >> maintainer commands. >> >> Just wanted to make sure my use case was noted. > > Thanks, here's what I pushed. > I'm seeing regressions, I'm assuming they're due to this patch: ... Running /data/vries/gdb/src/gdb/testsuite/gdb.dwarf2/dw2-out-of-range-end-of-seq.exp ... FAIL: gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: END with address 1 eliminated Running /data/vries/gdb/src/gdb/testsuite/gdb.dwarf2/dw2-ranges-base.exp ... FAIL: gdb.dwarf2/dw2-ranges-base.exp: count END markers in line table Running /data/vries/gdb/src/gdb/testsuite/gdb.base/maint.exp ... ERROR: internal buffer is full. ERROR: internal buffer is full. ... Thanks, - Tom > Simon > > > From 904d9b02a185c9048cf17bf7295b89d7380cea3d Mon Sep 17 00:00:00 2001 > From: Simon Marchi <simon.marchi@efficios.com> > Date: Thu, 16 Mar 2023 16:30:34 -0400 > Subject: [PATCH] gdb: make "maintenance info line-table" show relocated > addresses again > > Commit 1acc9dca423f ("Change linetables to be objfile-independent") > changed "maintenance info line-table" to print unrelocated addresses > instead of relocated. This breaks a few tests on systems where that > matters. The ones I see are: > > Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/consecutive.exp ... > FAIL: gdb.base/consecutive.exp: stopped at bp, 2nd instr (missing hex prefix) > Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/async.exp ... > FAIL: gdb.base/async.exp: stepi& > FAIL: gdb.base/async.exp: nexti& > FAIL: gdb.base/async.exp: finish& > > These tests run "maintenance info line-table" to record the address of > some lines, and then use these addresses in expected patterns. It > therefore expects these addresses to match the runtime addresses, > therefore the relocated addresses. > > Add back the relocated addresses, next to the unrelocated addresses, > like so: > > INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END > 0 6 0x0000555555555119 0x0000000000001119 Y > 1 7 0x000055555555511d 0x000000000000111d Y > 2 8 0x0000555555555123 0x0000000000001123 Y > 3 END 0x0000555555555125 0x0000000000001125 Y > > The unrelocated addresses can always be useful trying to map this > information with a DWARF info dump. > > Adjust the is_stmt_addresses proc in the testsuite to match the new > output. > > Change-Id: I59558f167e13e63421c9e0f2cad192e7c95c10cf > --- > gdb/symmisc.c | 9 ++++++--- > gdb/testsuite/lib/gdb.exp | 2 +- > 2 files changed, 7 insertions(+), 4 deletions(-) > > diff --git a/gdb/symmisc.c b/gdb/symmisc.c > index 54dc570d282f..a09b541f1b39 100644 > --- a/gdb/symmisc.c > +++ b/gdb/symmisc.c > @@ -976,10 +976,11 @@ maintenance_print_one_line_table (struct symtab *symtab, void *data) > /* Leave space for 6 digits of index and line number. After that the > tables will just not format as well. */ > struct ui_out *uiout = current_uiout; > - ui_out_emit_table table_emitter (uiout, 5, -1, "line-table"); > + ui_out_emit_table table_emitter (uiout, 6, -1, "line-table"); > uiout->table_header (6, ui_left, "index", _("INDEX")); > uiout->table_header (6, ui_left, "line", _("LINE")); > - uiout->table_header (18, ui_left, "address", _("ADDRESS")); > + uiout->table_header (18, ui_left, "rel-address", _("REL-ADDRESS")); > + uiout->table_header (18, ui_left, "unrel-address", _("UNREL-ADDRESS")); > uiout->table_header (7, ui_left, "is-stmt", _("IS-STMT")); > uiout->table_header (12, ui_left, "prologue-end", _("PROLOGUE-END")); > uiout->table_body (); > @@ -995,7 +996,9 @@ maintenance_print_one_line_table (struct symtab *symtab, void *data) > uiout->field_signed ("line", item->line); > else > uiout->field_string ("line", _("END")); > - uiout->field_core_addr ("address", objfile->arch (), > + uiout->field_core_addr ("rel-address", objfile->arch (), > + item->pc (objfile)); > + uiout->field_core_addr ("unrel-address", objfile->arch (), > CORE_ADDR (item->raw_pc ())); > uiout->field_string ("is-stmt", item->is_stmt ? "Y" : ""); > uiout->field_string ("prologue-end", item->prologue_end ? "Y" : ""); > diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp > index 0a0ae697d1ee..6c2d7e1c74e5 100644 > --- a/gdb/testsuite/lib/gdb.exp > +++ b/gdb/testsuite/lib/gdb.exp > @@ -8872,7 +8872,7 @@ proc is_stmt_addresses { file } { > set is_stmt [list] > > gdb_test_multiple "maint info line-table $file" "" { > - -re "\r\n$decimal\[ \t\]+$decimal\[ \t\]+($hex)\[ \t\]+Y\[^\r\n\]*" { > + -re "\r\n$decimal\[ \t\]+$decimal\[ \t\]+($hex)\[ \t\]+$hex\[ \t\]+Y\[^\r\n\]*" { > lappend is_stmt $expect_out(1,string) > exp_continue > } > > base-commit: bcefc6be9754d45fb9391993e6daaf01a68d9bd5
On 3/22/23 09:46, Tom de Vries wrote: > On 3/22/23 02:35, Simon Marchi via Gdb-patches wrote: >> >>> I'm never going to complain about more information. Especially not in >>> maintainer commands. >>> >>> Just wanted to make sure my use case was noted. >> >> Thanks, here's what I pushed. >> > > I'm seeing regressions, I'm assuming they're due to this patch: > ... > Running /data/vries/gdb/src/gdb/testsuite/gdb.dwarf2/dw2-out-of-range-end-of-seq.exp ... > FAIL: gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: END with address 1 eliminated > Running /data/vries/gdb/src/gdb/testsuite/gdb.dwarf2/dw2-ranges-base.exp ... > FAIL: gdb.dwarf2/dw2-ranges-base.exp: count END markers in line table > Running /data/vries/gdb/src/gdb/testsuite/gdb.base/maint.exp ... > ERROR: internal buffer is full. > ERROR: internal buffer is full. Yeah, I just found that too, looking into it. Simon
diff --git a/gdb/symmisc.c b/gdb/symmisc.c index 54dc570d282f..8296857d06c3 100644 --- a/gdb/symmisc.c +++ b/gdb/symmisc.c @@ -996,7 +996,7 @@ maintenance_print_one_line_table (struct symtab *symtab, void *data) else uiout->field_string ("line", _("END")); uiout->field_core_addr ("address", objfile->arch (), - CORE_ADDR (item->raw_pc ())); + item->pc (objfile)); uiout->field_string ("is-stmt", item->is_stmt ? "Y" : ""); uiout->field_string ("prologue-end", item->prologue_end ? "Y" : ""); uiout->text ("\n");