* [PATCH] [gdb/tui] Don't disassemble non-code sections and section holes
@ 2026-08-19 14:35 Tom de Vries
2026-09-02 16:30 ` [PING][PATCH] " Tom de Vries
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Tom de Vries @ 2026-08-19 14:35 UTC (permalink / raw)
To: gdb-patches
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PING][PATCH] [gdb/tui] Don't disassemble non-code sections and section holes
2026-08-19 14:35 [PATCH] [gdb/tui] Don't disassemble non-code sections and section holes Tom de Vries
@ 2026-09-02 16:30 ` Tom de Vries
2026-09-04 11:39 ` [PATCH] " Guinevere Larsen
2026-09-04 15:45 ` Andrew Burgess
2 siblings, 0 replies; 7+ messages in thread
From: Tom de Vries @ 2026-09-02 16:30 UTC (permalink / raw)
To: gdb-patches
On 8/19/26 4:35 PM, Tom de Vries wrote:
> 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;
> ...
>
Ping.
Thanks,
- Tom
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] [gdb/tui] Don't disassemble non-code sections and section holes
2026-08-19 14:35 [PATCH] [gdb/tui] Don't disassemble non-code sections and section holes Tom de Vries
2026-09-02 16:30 ` [PING][PATCH] " Tom de Vries
@ 2026-09-04 11:39 ` Guinevere Larsen
2026-09-09 10:41 ` Tom de Vries
2026-09-04 15:45 ` Andrew Burgess
2 siblings, 1 reply; 7+ messages in thread
From: Guinevere Larsen @ 2026-09-04 11:39 UTC (permalink / raw)
To: Tom de Vries, gdb-patches
On 8/19/26 11:35 AM, Tom de Vries wrote:
> 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
> ---
Hi!
Thank you for working on this!
I think your fix makes perfect sense, but I noticed an inaccuracy in the
function comment. It predates your change, but I think now would be a
reasonable time to fix it. The comment reads:
Function to disassemble up to COUNT instructions starting from
address PC
into the ASM_LINES vector (which will be emptied of any previous
contents).
Return the address of the COUNT'th instruction after pc.
Considering that returning early is possible, I think this comment
should say that we return the address right after the last disassembled
instruction, or something to that effect.
Also, I tried to reproduce this issue in x86 but couldn't. It would be
nice if there was a test that exercised this, but it isn't a requirement
for me.
--
Cheers,
Guinevere Larsen
it/its
she/her (deprecated)
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] [gdb/tui] Don't disassemble non-code sections and section holes
2026-08-19 14:35 [PATCH] [gdb/tui] Don't disassemble non-code sections and section holes Tom de Vries
2026-09-02 16:30 ` [PING][PATCH] " Tom de Vries
2026-09-04 11:39 ` [PATCH] " Guinevere Larsen
@ 2026-09-04 15:45 ` Andrew Burgess
2026-09-09 11:27 ` Tom de Vries
2 siblings, 1 reply; 7+ messages in thread
From: Andrew Burgess @ 2026-09-04 15:45 UTC (permalink / raw)
To: Tom de Vries, gdb-patches
Tom de Vries <tdevries@suse.de> writes:
> 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;
> ...
TUI disassembly has been an ongoing issue for as long as I've been
contributing to GDB :-/ Getting the logic right for scrolling
forward/backward has always been an issue.
I'm not sure this change is the right fix though. I have two concerns.
In CLI mode, if I stop the inferior and then use `disassemble START,END`
syntax, then I can disassemble any range of memory, not just executable
sections.
If I switch to TUI mode, without this patch and try the same disassemble
command then I'll get a screen full of instructions starting at START.
Is that useful given these aren't code sections? I'm not really sure.
But if I apply your patch and try the same disassemble command then I
get a blank ASM window.
There are for sure ways that a user can work around this, `x/i` will
dump the instructions to the CMD window, even in TUI mode. But the
blank window still looks wrong to me, and I think it is not what users
will expect.
The other problem I see is that this will, if I understand correctly,
prevent disassembly of memory that is not backed by an ELF section. For
example, a JIT compiling interpreter. Given such a tool I'd expect to
be able to disassemble the generated code regions, but these will likely
not be backed by an ELF section.
Thanks,
Andrew
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] [gdb/tui] Don't disassemble non-code sections and section holes
2026-09-04 11:39 ` [PATCH] " Guinevere Larsen
@ 2026-09-09 10:41 ` Tom de Vries
2026-09-09 11:19 ` Guinevere Larsen
0 siblings, 1 reply; 7+ messages in thread
From: Tom de Vries @ 2026-09-09 10:41 UTC (permalink / raw)
To: Guinevere Larsen, gdb-patches
On 9/4/26 1:39 PM, Guinevere Larsen wrote:
> On 8/19/26 11:35 AM, Tom de Vries wrote:
>> 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
>> ---
>
> Hi!
>
> Thank you for working on this!
>
Hi Guinevere,
thanks for the review.
> I think your fix makes perfect sense, but I noticed an inaccuracy in the
> function comment. It predates your change, but I think now would be a
> reasonable time to fix it. The comment reads:
>
> Function to disassemble up to COUNT instructions starting from
> address PC
> into the ASM_LINES vector (which will be emptied of any previous
> contents).
> Return the address of the COUNT'th instruction after pc.
>
> Considering that returning early is possible, I think this comment
> should say that we return the address right after the last disassembled
> instruction, or something to that effect.
>
Agreed. I've added a patch in a v2 (
https://sourceware.org/pipermail/gdb-patches/2026-September/230205.html ).
> Also, I tried to reproduce this issue in x86 but couldn't. It would be
> nice if there was a test that exercised this, but it isn't a requirement
> for me.
As for reproducing, initially I worked with the exec reported in the PR,
but Andrew's comment in his review made me realize I could use the
disassemble command to update the asm window.
Then I managed to reproduce it quite easily using a hello world exec:
...
$ gcc -g hello.c
...
The steps are:
- find a section hole using readelf -S a.out. I found one in between
.init and .plt.
- use the disassemble command to disassemble the section before the
section hole. In my case: "disassemble _init"
- scroll forward until .init is no longer visible (and maybe one
instruction more)
- try to scroll back into _init
I used this command for most of the setup:
...
$ gdb -q -iex "set debuginfod enabled off" a.out -ex start -ex "layout
asm" -ex "disassemble _init"
...
Note that there's a start in there. If that's not there, then we can't
scroll forward through the section hole to begin with.
Indeed IWBN if there was a test-case, but I'm not sure how to build a
non-fragile architecture-neutral assembly file that is sure to have a
section hole.
Thanks,
- Tom
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] [gdb/tui] Don't disassemble non-code sections and section holes
2026-09-09 10:41 ` Tom de Vries
@ 2026-09-09 11:19 ` Guinevere Larsen
0 siblings, 0 replies; 7+ messages in thread
From: Guinevere Larsen @ 2026-09-09 11:19 UTC (permalink / raw)
To: Tom de Vries, gdb-patches
On 9/9/26 7:41 AM, Tom de Vries wrote:
> On 9/4/26 1:39 PM, Guinevere Larsen wrote:
>> On 8/19/26 11:35 AM, Tom de Vries wrote:
>>> 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
>>> ---
>>
>> Hi!
>>
>> Thank you for working on this!
>>
>
> Hi Guinevere,
>
> thanks for the review.
>
>> I think your fix makes perfect sense, but I noticed an inaccuracy in
>> the function comment. It predates your change, but I think now would
>> be a reasonable time to fix it. The comment reads:
>>
>> Function to disassemble up to COUNT instructions starting from
>> address PC
>> into the ASM_LINES vector (which will be emptied of any previous
>> contents).
>> Return the address of the COUNT'th instruction after pc.
>>
>> Considering that returning early is possible, I think this comment
>> should say that we return the address right after the last
>> disassembled instruction, or something to that effect.
>>
>
> Agreed. I've added a patch in a v2 (
> https://sourceware.org/pipermail/gdb-patches/2026-September/230205.html
> ).
>
>> Also, I tried to reproduce this issue in x86 but couldn't. It would
>> be nice if there was a test that exercised this, but it isn't a
>> requirement for me.
>
> As for reproducing, initially I worked with the exec reported in the
> PR, but Andrew's comment in his review made me realize I could use the
> disassemble command to update the asm window.
>
> Then I managed to reproduce it quite easily using a hello world exec:
> ...
> $ gcc -g hello.c
> ...
>
> The steps are:
> - find a section hole using readelf -S a.out. I found one in between
> .init and .plt.
> - use the disassemble command to disassemble the section before the
> section hole. In my case: "disassemble _init"
> - scroll forward until .init is no longer visible (and maybe one
> instruction more)
> - try to scroll back into _init
>
> I used this command for most of the setup:
> ...
> $ gdb -q -iex "set debuginfod enabled off" a.out -ex start -ex "layout
> asm" -ex "disassemble _init"
> ...
>
> Note that there's a start in there. If that's not there, then we
> can't scroll forward through the section hole to begin with.
>
> Indeed IWBN if there was a test-case, but I'm not sure how to build a
> non-fragile architecture-neutral assembly file that is sure to have a
> section hole.
My idea was to have a .S with a code section and then a non-code
section, to ensure that the non-code wouldn't be disassembled. But with
Andrew's review I see that that should be changed so it makes sense to
not have the test.
>
> Thanks,
> - Tom
>
--
Cheers,
Guinevere Larsen
it/its
she/her (deprecated)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] [gdb/tui] Don't disassemble non-code sections and section holes
2026-09-04 15:45 ` Andrew Burgess
@ 2026-09-09 11:27 ` Tom de Vries
0 siblings, 0 replies; 7+ messages in thread
From: Tom de Vries @ 2026-09-09 11:27 UTC (permalink / raw)
To: Andrew Burgess, gdb-patches
On 9/4/26 5:45 PM, Andrew Burgess wrote:
> Tom de Vries <tdevries@suse.de> writes:
>
>> 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;
>> ...
>
> TUI disassembly has been an ongoing issue for as long as I've been
> contributing to GDB :-/ Getting the logic right for scrolling
> forward/backward has always been an issue.
>
> I'm not sure this change is the right fix though. I have two concerns.
>
> In CLI mode, if I stop the inferior and then use `disassemble START,END`
> syntax, then I can disassemble any range of memory, not just executable
> sections.
>
> If I switch to TUI mode, without this patch and try the same disassemble
> command then I'll get a screen full of instructions starting at START.
Hi Andrew,
thanks for the review.
I see your point. I've submitted now a v2 that drops this restrictive
approach, and instead tries to enable scrolling up and down as much as
possible (
https://sourceware.org/pipermail/gdb-patches/2026-September/230207.html ).
> Is that useful given these aren't code sections? I'm not really sure.
>
Yeah. I filed a related PR (
https://sourceware.org/bugzilla/show_bug.cgi?id=34604 ).
> But if I apply your patch and try the same disassemble command then I
> get a blank ASM window.
>
> There are for sure ways that a user can work around this, `x/i` will
> dump the instructions to the CMD window, even in TUI mode. But the
> blank window still looks wrong to me, and I think it is not what users
> will expect.
>
Agreed.
> The other problem I see is that this will, if I understand correctly,
> prevent disassembly of memory that is not backed by an ELF section. For
> example, a JIT compiling interpreter. Given such a tool I'd expect to
> be able to disassemble the generated code regions, but these will likely
> not be backed by an ELF section.
Good point. I've made a note the JIT scenario in aforementioned PR.
Thanks,
- Tom
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2026-09-09 11:27 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-08-19 14:35 [PATCH] [gdb/tui] Don't disassemble non-code sections and section holes Tom de Vries
2026-09-02 16:30 ` [PING][PATCH] " Tom de Vries
2026-09-04 11:39 ` [PATCH] " Guinevere Larsen
2026-09-09 10:41 ` Tom de Vries
2026-09-09 11:19 ` Guinevere Larsen
2026-09-04 15:45 ` Andrew Burgess
2026-09-09 11:27 ` Tom de Vries
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox