Bug 1859714

Summary: Gdb really needs an enhanced assembly stepping mode
Product: Red Hat Enterprise Linux 8 Reporter: Ben Crocker <bcrocker>
Component: gdbAssignee: Keith Seitz <keiths>
gdb sub component: system-version QA Contact: qe-baseos-tools-bugs
Status: CLOSED UPSTREAM Docs Contact:
Severity: high    
Priority: unspecified CC: dsmith, gdb-bugs, keiths, ohudlick, palves, sergiodj
Version: 8.3Keywords: FutureFeature, Triaged
Target Milestone: rc   
Target Release: 8.0   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-04-15 18:21:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ben Crocker 2020-07-22 18:40:28 UTC
Description of problem:

Gdb really needs an enhanced assembly stepping mode that will print,
not just the instructions themselves, but also the inputs and outputs.

For example, on POWER, if the current instruction is add r9, r1, r2:

(gdb) stepi
    # would print
<address expression>:     <previous instruction>
    r1 = 15 (0x0F)  r2 = 14 (0x0E)
<current address>:        add  r9, r1, r2
    r9 = 29 (0x1D)
<address expression>:     <next instruction>

(gdb)

Version-Release number of selected component (if applicable):

gdb 8.2-12

How reproducible:

100%

Steps to Reproduce:
1. gdb any program
2. (gdb) set disassemble-next-line on
3. stop on any line
4. proceed w/ stepi

Actual results:

Old behavior: the current instruction is executed;
surrounding instructions are disassembled.

If I want to examine inputs and outputs, I have to
enter additional commands (info reg ..., x/x <location>,
etc.)  This is less than ideal, as
a. it's a lot more (and potentially error-prone) typing, and
b. some inputs may be overwritten by outputs.

Expected results:

Something like what I described above; exact form
negotiable.


Additional info:

Comment 1 Pedro Alves 2020-08-07 19:33:44 UTC
Not exactly what you suggested, but have you ever tried GDB's built-in ncurses
mode (aka, the TUI)?

  https://sourceware.org/gdb/onlinedocs/gdb/TUI.html

If you do:

  (gdb) layout asm
  (gdb) layout regs

that brings up a view that shows the current contents of registers.

And then, if you stepi a number of times, you'll see that GDB highlights
the registers that change.  

You can also switch in and out of the TUI with "c-x a", and then cycle
to the regs layout with "c-x 2":

  https://sourceware.org/gdb/onlinedocs/gdb/TUI-Keys.html

Comment 2 Ben Crocker 2020-09-21 16:15:04 UTC
Hi Pedro and Keith,

I am, indeed, aware of the Text User Interface, and have even used it
on occasion.

However, the model starts to break down on architectures with large
numbers of registers, e.g. Power with
• 32 64-bit integer registers
• 32 64-bit floating point registers
• 32 128-bit vector registers
• 64 128-bit "vector scalar" registers
Additionally, all the vector registers can be interpreted in any of
several ways:
• 2 64-bit double precision floats
• 4 32-bit single precision floats
• 8 16-bit half-precision floats
• 2 64-bit integers
• 4 32-bit integers
• 8 16-bit integers
• 16 8-bit integers

All the other architectures we're interested in also have large
register sets, including floating point registers and vector registers
that can be interpreted in several ways, depending on the instruction.

I want to try to get away from a response I've seen before in the
Linux world, one which ultimately doesn't help: "This feature does
ALMOST what you want, so... problem solved!"

What I want to see is:
• the instruction (or higher-level language statement) I'm about to execute;
• the inputs (register[s] and, if applicable, memory) BEFORE the instruction/statement is executed;
• the outputs (again, register[s] and, if applicable, memory) AFTER execution.

As you point out in your response, GDB highlights registers that
change, but does NOT highlight input registers.

AND, it makes me hunt for the information I want, rather than
presenting it in a more user-friendly way.

Comment 3 Keith Seitz 2020-09-25 19:47:43 UTC
I completely sympathize with your predicament. It would definitely be a neat feature!

While we can suggest ways to help you accomplish certain tasks, like displaying
the current source line/instruction or displaying only certain registers,
we are, unfortunately, in no current position to give you what you need in the
foreseeable future.

I am not going to change the state on this bug (I'll let the PO do that) because
I think this could be an amazing feature. [I wonder if the Labs or $BIG_CUSTOMER
would have any interest in this?]

I am afraid all I can do is encourage you to ask about how we might be able to help you today.

Comment 6 Keith Seitz 2021-04-15 18:21:02 UTC
Moving upstream