public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug cli/30346] [gdb/cli] CLI in ansi terminal has off-by-one width problem
Date: Fri, 12 May 2023 09:43:48 +0000	[thread overview]
Message-ID: <bug-30346-4717-yHMowxowaf@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-30346-4717@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=30346

--- Comment #4 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f0f6df0a04fe521ff4df9b74981a624fa2583e3a

commit f0f6df0a04fe521ff4df9b74981a624fa2583e3a
Author: Tom de Vries <tdevries@suse.de>
Date:   Fri May 12 11:43:41 2023 +0200

    [gdb/cli] Fix wrapping for TERM=ansi

    I. Auto-detected width (xterm vs. ansi)

    Say we have a terminal with a width of 40 chars:
    ...
    $ echo $COLUMNS
    40
    ...

    With TERM=xterm, we report a width of 40 chars:
    ...
    $ TERM=xterm gdb
    (gdb) show width
    Number of characters gdb thinks are in a line is 40.
    ...

    And with TERM=ansi, a width of 39 chars:
    ...
    $ TERM=ansi gdb
    (gdb) show width
    Number of characters gdb thinks are in a line is 39.
    ...

    Gdb uses readline to auto-detect screen size, and readline decides in the
    TERM=ansi case that the terminal does not have reliable auto-wrap, and
    consequently decides to hide the last terminal column from the readline
user
    (in other words GDB), hence we get 39 instead of 40.

    II. Types of wrapping

    Looking a bit more in detail inside gdb, it seems there are two types of
    wrapping:
    - readline wrapping (in other words, prompt edit wrapping), and
    - gdb output wrapping (can be observed by issuing "info sources").
      This type of wrapping attempts to wrap some of the gdb output earlier
      than the indicated width, to not break lines in inconvenient places.

    III. Readline wrapping, auto-detected screen size

    Let's investigate readline wrapping with the auto-detected screen widths.

    First, let's try with xterm:
    ...
    $ TERM=xterm gdb
    (gdb) 7890123456789012345678901234567890
    123
    ...
    That looks as expected, wrapping occurs after 40 chars.

    Now, let's try with ansi:
    ...
    $ TERM=ansi gdb
    (gdb) 78901234567890123456789012345678
    90123
    ...
    It looks like wrapping occurred after 38, while readline should be capable
of
    wrapping after 39 chars.

    This is caused by readline hiding the last column, twice.

    In more detail:
    - readline detects the screen width: 40,
    - readline hides the last column, setting the readline screen width to 39,
    - readline reports 39 to gdb as screen width,
    - gdb sets its width setting to 39,
    - gdb sets readline screen width to 39,
    - readline hides the last column, again, setting the readline screen width
to
      38.

    This is reported as PR cli/30346.

    IV. gdb output wrapping, auto-detected screen size

    Say we set the terminal width to 56. With TERM=xterm, we have:
    ...
    /home/abuild/rpmbuild/BUILD/glibc-2.31/csu/elf-init.c,
    /data/vries/hello.c,
    ...
    but with TERM=ansi:
    ...
    /home/abuild/rpmbuild/BUILD/glibc-2.31/csu/elf-init.c, /
    data/vries/hello.c,
    ...

    So what happened here?  With TERM=ansi, the width setting is auto-detected
to
    55, and gdb assumes the terminal inserts a line break there, which it
doesn't
    because the terminal width is 56.

    This is reported as PR cli/30411.

    V. Fix PRs

    Fix both mentioned PRs by taking into account the hidden column when
readline
    reports the screen width in init_page_info, and updating chars_per_line
    accordingly.

    Note that now we report the same width for both TERM=xterm and TERM=ansi,
    which is much clearer.

    The point where readline respectively expects or ensures wrapping is still
    indicated by "maint info screen", for xterm:
    ...
    Number of characters readline reports are in a line is 40.
    ...
    and ansi:
    ...
    Number of characters readline reports are in a line is 39.
    ...

    VI. Testing

    PR cli/30346 is covered by existing regression tests gdb.base/wrap-line.exp
    and gdb.tui/wrap-line.exp, so remove the KFAILs there.

    I didn't manage to come up with a regression test for PR cli/30411. 
Perhaps
    that would be easier if we had a maintenance command that echoes its
arguments
    while applying gdb output wrapping.

    Tested on x86_64-linux.

    PR cli/30346
    PR cli/30411
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30346
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30411

-- 
You are receiving this mail because:
You are on the CC list for the bug.

  parent reply	other threads:[~2023-05-12  9:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-13 12:42 [Bug cli/30346] New: " vries at gcc dot gnu.org
2023-04-15  6:10 ` [Bug cli/30346] " vries at gcc dot gnu.org
2023-04-21 15:12 ` cvs-commit at gcc dot gnu.org
2023-05-05 12:34 ` cvs-commit at gcc dot gnu.org
2023-05-12  9:43 ` cvs-commit at gcc dot gnu.org [this message]
2023-05-12  9:46 ` vries at gcc dot gnu.org

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=bug-30346-4717-yHMowxowaf@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@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).