From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Subject: [PATCH] [gdb/tui] Don't disassemble non-code sections and section holes
Date: Wed, 19 Aug 2026 16:35:14 +0200 [thread overview]
Message-ID: <20260819143514.2221499-1-tdevries@suse.de> (raw)
I was investigating TUI behaviour on ppc64-linux using the executable from
test-case gdb.tui/basic.exp, and after scrolling in the asm window ended up
with:
...
+----------------------------------------------------------------------------+
| 0x920 <__libc_start_main@plt+4> b 0x8f0 <__glink_PLTresolve> |
| 0x924 <__gmon_start__@plt> li r0,1 |
| 0x928 <__gmon_start__@plt+4> b 0x8f0 <__glink_PLTresolve> |
| 0x92c <__cxa_finalize@plt> li r0,2 |
| 0x930 <__cxa_finalize@plt+4> b 0x8f0 <__glink_PLTresolve> |
| 0x934 <._fini> mflr r0 |
| 0x938 <._fini+4> std r0,16(r1) |
| 0x93c <._fini+8> stdu r1,-112(r1) |
| 0x940 <._fini+12> addi r1,r1,112 |
| 0x944 <._fini+16> ld r0,16(r1) |
| 0x948 <._fini+20> mtlr r0 |
| 0x94c <._fini+24> blr |
| 0x950 <_IO_stdin_used> .long 0x20001 |
| 0x954 .long 0x11b033b |
| 0x958 .long 0x18 |
| 0x95c .long 0x2 |
| 0x960 .long 0xffffff60 |
| 0x964 .long 0x48 |
| 0x968 .long 0xffffff9c |
| 0x96c .long 0x30 |
+----------------------------------------------------------------------------+
exec No process (asm) In: L?? PC: ??
(gdb)
...
The view corresponds to this objdump -D output:
...
Disassembly of section .text:
...
000000000000091c <__libc_start_main@plt>:
91c: 38 00 00 00 li r0,0
920: 4b ff ff d0 b 8f0 <__glink_PLTresolve>
0000000000000924 <__gmon_start__@plt>:
924: 38 00 00 01 li r0,1
928: 4b ff ff c8 b 8f0 <__glink_PLTresolve>
000000000000092c <__cxa_finalize@plt>:
92c: 38 00 00 02 li r0,2
930: 4b ff ff c0 b 8f0 <__glink_PLTresolve>
Disassembly of section .fini:
0000000000000934 <._fini>:
934: 7c 08 02 a6 mflr r0
938: f8 01 00 10 std r0,16(r1)
93c: f8 21 ff 91 stdu r1,-112(r1)
940: 38 21 00 70 addi r1,r1,112
944: e8 01 00 10 ld r0,16(r1)
948: 7c 08 03 a6 mtlr r0
94c: 4e 80 00 20 blr
Disassembly of section .rodata:
0000000000000950 <_IO_stdin_used>:
950: 00 02 00 01 .long 0x20001
Disassembly of section .eh_frame_hdr:
0000000000000954 <__GNU_EH_FRAME_HDR>:
954: 01 1b 03 3b .long 0x11b033b
958: 00 00 00 18 .long 0x18
95c: 00 00 00 02 .long 0x2
960: ff ff ff 60 .long 0xffffff60
964: 00 00 00 48 .long 0x48
968: ff ff ff 9c .long 0xffffff9c
96c: 00 00 00 30 .long 0x30
...
ISTM that we should not be disassembling the .rodata section.
My first thought was to require tui_disassemble to stay in the same section,
but after thinking about it a bit more decided that that was too restrictive,
and instead went for requiring that we stay in code sections.
So, I came up with this fix:
...
struct obj_section *section = find_pc_section (pc);
if (section != nullptr
&& (bfd_section_flags (section->the_bfd_section) & SEC_CODE) == 0)
return pc;
...
Then I stumbled on PR tui/34399, which reports not being able to scroll back
up after scrolling down. The problem there is that we disassemble code from a
section hole (0x401034-0x402000):
...
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .note.gnu.pr[...] NOTE 0000000000400190 00000190
0000000000000030 0000000000000000 A 0 0 8
[ 2] .note.gnu.bu[...] NOTE 00000000004001c0 000001c0
0000000000000024 0000000000000000 A 0 0 4
[ 3] .text PROGBITS 0000000000401000 00001000
0000000000000034 0000000000000000 AX 0 0 1
[ 4] .rodata PROGBITS 0000000000402000 00002000
0000000000000006 0000000000000000 A 0 0 1
[ 5] .symtab SYMTAB 0000000000000000 00002008
0000000000000078 0000000000000018 6 1 8
[ 6] .strtab STRTAB 0000000000000000 00002080
0000000000000019 0000000000000000 0 0 1
[ 7] .shstrtab STRTAB 0000000000000000 00002099
000000000000004f 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
D (mbind), l (large), p (processor specific)
...
and once we call tui_find_backward_disassembly_start_address with an address
ADDR for which find_pc_section (ADDR - 1) == nullptr, we are stuck in the
section hole.
Fix this by not disassembling section holes.
This is achieved by slightly modifying the earlier fix:
...
if (section == nullptr
|| (bfd_section_flags (section->the_bfd_section) & SEC_CODE) == 0)
return pc;
...
Tested on x86_64-linux and ppc64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34399
---
gdb/tui/tui-disasm.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/gdb/tui/tui-disasm.c b/gdb/tui/tui-disasm.c
index 5c68312a91b..085a6c2903e 100644
--- a/gdb/tui/tui-disasm.c
+++ b/gdb/tui/tui-disasm.c
@@ -112,6 +112,15 @@ tui_disassemble (struct gdbarch *gdbarch,
{
tui_asm_line tal;
+ /* Don't disassemble:
+ - non-code sections (not appropriate for disassembly window), and
+ - section holes (otherwise we can get stuck, unable to scroll back to
+ the section before the section hole). */
+ struct obj_section *section = find_pc_section (pc);
+ if (section == nullptr
+ || (bfd_section_flags (section->the_bfd_section) & SEC_CODE) == 0)
+ return pc;
+
/* Save the instruction address. */
tal.addr = pc;
base-commit: 4ed310516eb76cbf650523a53f733060d3ae71b9
--
2.51.0
reply other threads:[~2026-08-19 14:35 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20260819143514.2221499-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