gdb: work around prompt corruption caused by bracketed-paste-mode
In this commit:
commit b4f26d541aa7224b70d363932e816e6e1a857633
Date: Tue Mar 2 13:42:37 2021 -0700
Import GNU Readline 8.1
We imported readline 8.1 into GDB. As a consequence bug PR cli/28833
was reported. This bug spotted that, when the user terminated GDB by
sending EOF (usually bound to Ctrl+d), the last prompt would become
corrupted. Here's what happens, the user is sat at a prompt like
this:
(gdb)
And then the user sends EOF (Ctrl+d), we now see this:
quit)
... gdb terminates, and we return to the shell ...
Notice the 'quit' was printed over the prompt.
This problem is a result of readline 8.1 enabling bracketed paste mode
by default. This problem is present in readline 8.0 too, but in that
version of readline bracketed paste mode is off by default, so a user
will not see the bug unless they specifically enable the feature.
Bracketed paste mode is available in readline 7.0 too, but the bug
is not present in this version of readline, see below for why.
What causes this problem is how readline disables bracketed paste
mode. Bracketed paste mode is a terminal feature that is enabled and
disabled by readline emitting a specific escape sequence. The problem
for GDB is that the escape sequence to disable bracketed paste mode
includes a '\r' character at the end, see this thread for more
details:
https://lists.gnu.org/archive/html/bug-bash/2018-01/msg00097.html
The change to add the '\r' character to the escape sequence used to
disable bracketed paste mode was introduced between readline 7.0 and
readline 8.0, this is why the bug would not occur when using older
versions of readline (note: I don't know if its even possible to build
GDB using readline 7.0. That really isn't important, I'm just
documenting the history of this issue).
So, the escape sequence to disable bracketed paste mode is emitted
from the readline function rl_deprep_terminal, this is called after
the user has entered a complete command and pressed return, or, if the
user sends EOF.
However, these two cases are slightly different. In the first case,
when the user has entered a command and pressed return, the cursor
will have moved to the next, empty, line, before readline emits the
escape sequence to leave bracketed paste mode. The final '\r'
character moves the cursor back to the beginning of this empty line,
which is harmless.
For the EOF case though, this is not what happens. Instead, the
escape sequence to leave bracketed paste mode is emitted on the same
line as the prompt. The final '\r' moves the cursor back to the start
of the prompt line. This leaves us ready to override the prompt.
It is worth noting, that this is not the intended behaviour of
readline, in rl_deprep_terminal, readline should emit a '\n' character
when EOF is seen. However, due to a bug in readline this does not
happen (the _rl_eof_found flag is never set). This is the first
readline bug that effects GDB.
GDB prints the 'quit' message from command_line_handler (in
event-top.c), this function is called (indirectly) from readline to
process the complete command line, but also in the EOF case (in which
case the command line is set to nullptr). As this is part of the
callback to process a complete command, this is called after readline
has disabled bracketed paste mode (by calling rl_deprep_terminal).
And so, when bracketed paste mode is in use, rl_deprep_terminal leaves
the cursor at the start of the prompt line (in the EOF case), and
command_line_handler then prints 'quit', which overwrites the prompt.
The solution to this problem is to print the 'quit' message earlier,
before rl_deprep_terminal is called. This is easy to do by using the
rl_deprep_term_function hook. It is this hook that usually calls
rl_deprep_terminal, however, if we replace this with a new function,
we can print the 'quit' string, and then call rl_deprep_terminal
ourselves. This allows the 'quit' to be printed before
rl_deprep_terminal is called.
The problem here is that there is no way in rl_deprep_terminal to know
if readline is processing EOF or not, and as a result, we don't know
when we should print 'quit'. This is the second readline bug that
effects GDB.
Both of these readline issues are discussed in this thread:
https://lists.gnu.org/archive/html/bug-readline/2022-02/msg00021.html
The result of that thread was that readline was patched to address
both of these issues.
Now it should be easy to backport the readline fix to GDB's in tree
copy of readline, and then change GDB to make use of these fixes to
correctly print the 'quit' string.
However, we are just about to branch GDB 12, and there is concern from
some that changing readline this close to a new release is a risky
idea, see this thread:
https://sourceware.org/pipermail/gdb-patches/2022-March/186391.html
So, this commit doesn't change readline at all. Instead, this commit
is the smallest possible GDB change in order to avoid the prompt
corruption.
In this commit I change GDB to print the 'quit' string on the line
after the prompt, but only when bracketed paste mode is on. This
avoids the overwriting issue, the user sees this:
(gdb)
quit
... gdb terminates, and returns to the shell ...
This isn't ideal, but is better than the existing behaviour. After
GDB 12 has branched, we can backport the readline fix, and apply a
real fix to GDB.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28833
2022-03-11 22:44:03 +08:00
|
|
|
# Copyright (C) 2022 Free Software Foundation, Inc.
|
|
|
|
|
|
|
|
# This program is free software; you can redistribute it and/or modify
|
|
|
|
# it under the terms of the GNU General Public License as published by
|
|
|
|
# the Free Software Foundation; either version 3 of the License, or
|
|
|
|
# (at your option) any later version.
|
|
|
|
#
|
|
|
|
# This program is distributed in the hope that it will be useful,
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
# GNU General Public License for more details.
|
|
|
|
#
|
|
|
|
# You should have received a copy of the GNU General Public License
|
|
|
|
# along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
|
|
|
# This test script checks how GDB handles exiting with ctrl-d.
|
|
|
|
|
|
|
|
# Start GDB, and then close it by sendig ctrl-d. Check that the
|
|
|
|
# string 'quit' appears where we expect it too.
|
|
|
|
proc run_test {} {
|
|
|
|
clean_restart
|
|
|
|
|
|
|
|
# The gdb_start call above swallows the GDB prompt, and we want
|
|
|
|
# the prompt for the test below.
|
|
|
|
#
|
|
|
|
# Send a newline character, which will cause GDB to redisplay the
|
|
|
|
# prompt.
|
gdb: fix for gdb.base/eof-exit.exp test failures
This fix relates to PR gdb/29032, this makes the test more stable by
ensuring that the Ctrl-D is only sent once the prompt has been
displayed. This issue was also discussed on the mailing list here:
https://sourceware.org/pipermail/gdb-patches/2022-April/187670.html
The problem identified in the bug report is that sometimes the Ctrl-D
(that the test sends to GDB) arrives while GDB is processing a
command. When this happens the Ctrl-D is handled differently than if
the Ctrl-D is sent while GDB is waiting for input at a prompt.
The original intent of the test was that the Ctrl-D be sent while GDB
was waiting at a prompt, and that is the case the occurs most often,
but, when the Ctrl-D arrives during command processing, then GDB will
ignore the Ctrl-D, and the test will fail.
This commit ensures the Ctrl-D is always sent while GDB is waiting at
a prompt, which makes this test stable.
But, that still leaves an open question, what should happen when the
Ctrl-D arrives while GDB is processing a command? This commit doesn't
attempt to answer that question, which is while bug PR gdb/29032 will
not be closed once this commit is merged.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29032
2022-04-20 21:08:49 +08:00
|
|
|
#
|
|
|
|
# We then consume the newline characters, and then make use of
|
|
|
|
# expect's -notransfer option to ensure that the prompt has been
|
|
|
|
# displayed, but to leave the prompt in expect's internal buffer.
|
|
|
|
# This is important as the following test wants to check how GDB
|
|
|
|
# displays the 'quit' message relative to the prompt, this is much
|
|
|
|
# easier to do if the prompt is still in expect's buffers.
|
|
|
|
#
|
|
|
|
# The other special thing we do here is avoid printing a 'PASS'
|
|
|
|
# result. The reason for this is so that the GDB output in the
|
|
|
|
# log file will match what a user should see, this makes it much
|
|
|
|
# easier to debug issues. Obviously we could print a 'PASS' here
|
|
|
|
# as the text printed by expect is not considered part of GDB's
|
|
|
|
# output, so the pattern matching will work just fine... but, the
|
|
|
|
# log file becomes much harder to read.
|
gdb: work around prompt corruption caused by bracketed-paste-mode
In this commit:
commit b4f26d541aa7224b70d363932e816e6e1a857633
Date: Tue Mar 2 13:42:37 2021 -0700
Import GNU Readline 8.1
We imported readline 8.1 into GDB. As a consequence bug PR cli/28833
was reported. This bug spotted that, when the user terminated GDB by
sending EOF (usually bound to Ctrl+d), the last prompt would become
corrupted. Here's what happens, the user is sat at a prompt like
this:
(gdb)
And then the user sends EOF (Ctrl+d), we now see this:
quit)
... gdb terminates, and we return to the shell ...
Notice the 'quit' was printed over the prompt.
This problem is a result of readline 8.1 enabling bracketed paste mode
by default. This problem is present in readline 8.0 too, but in that
version of readline bracketed paste mode is off by default, so a user
will not see the bug unless they specifically enable the feature.
Bracketed paste mode is available in readline 7.0 too, but the bug
is not present in this version of readline, see below for why.
What causes this problem is how readline disables bracketed paste
mode. Bracketed paste mode is a terminal feature that is enabled and
disabled by readline emitting a specific escape sequence. The problem
for GDB is that the escape sequence to disable bracketed paste mode
includes a '\r' character at the end, see this thread for more
details:
https://lists.gnu.org/archive/html/bug-bash/2018-01/msg00097.html
The change to add the '\r' character to the escape sequence used to
disable bracketed paste mode was introduced between readline 7.0 and
readline 8.0, this is why the bug would not occur when using older
versions of readline (note: I don't know if its even possible to build
GDB using readline 7.0. That really isn't important, I'm just
documenting the history of this issue).
So, the escape sequence to disable bracketed paste mode is emitted
from the readline function rl_deprep_terminal, this is called after
the user has entered a complete command and pressed return, or, if the
user sends EOF.
However, these two cases are slightly different. In the first case,
when the user has entered a command and pressed return, the cursor
will have moved to the next, empty, line, before readline emits the
escape sequence to leave bracketed paste mode. The final '\r'
character moves the cursor back to the beginning of this empty line,
which is harmless.
For the EOF case though, this is not what happens. Instead, the
escape sequence to leave bracketed paste mode is emitted on the same
line as the prompt. The final '\r' moves the cursor back to the start
of the prompt line. This leaves us ready to override the prompt.
It is worth noting, that this is not the intended behaviour of
readline, in rl_deprep_terminal, readline should emit a '\n' character
when EOF is seen. However, due to a bug in readline this does not
happen (the _rl_eof_found flag is never set). This is the first
readline bug that effects GDB.
GDB prints the 'quit' message from command_line_handler (in
event-top.c), this function is called (indirectly) from readline to
process the complete command line, but also in the EOF case (in which
case the command line is set to nullptr). As this is part of the
callback to process a complete command, this is called after readline
has disabled bracketed paste mode (by calling rl_deprep_terminal).
And so, when bracketed paste mode is in use, rl_deprep_terminal leaves
the cursor at the start of the prompt line (in the EOF case), and
command_line_handler then prints 'quit', which overwrites the prompt.
The solution to this problem is to print the 'quit' message earlier,
before rl_deprep_terminal is called. This is easy to do by using the
rl_deprep_term_function hook. It is this hook that usually calls
rl_deprep_terminal, however, if we replace this with a new function,
we can print the 'quit' string, and then call rl_deprep_terminal
ourselves. This allows the 'quit' to be printed before
rl_deprep_terminal is called.
The problem here is that there is no way in rl_deprep_terminal to know
if readline is processing EOF or not, and as a result, we don't know
when we should print 'quit'. This is the second readline bug that
effects GDB.
Both of these readline issues are discussed in this thread:
https://lists.gnu.org/archive/html/bug-readline/2022-02/msg00021.html
The result of that thread was that readline was patched to address
both of these issues.
Now it should be easy to backport the readline fix to GDB's in tree
copy of readline, and then change GDB to make use of these fixes to
correctly print the 'quit' string.
However, we are just about to branch GDB 12, and there is concern from
some that changing readline this close to a new release is a risky
idea, see this thread:
https://sourceware.org/pipermail/gdb-patches/2022-March/186391.html
So, this commit doesn't change readline at all. Instead, this commit
is the smallest possible GDB change in order to avoid the prompt
corruption.
In this commit I change GDB to print the 'quit' string on the line
after the prompt, but only when bracketed paste mode is on. This
avoids the overwriting issue, the user sees this:
(gdb)
quit
... gdb terminates, and returns to the shell ...
This isn't ideal, but is better than the existing behaviour. After
GDB 12 has branched, we can backport the readline fix, and apply a
real fix to GDB.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28833
2022-03-11 22:44:03 +08:00
|
|
|
send_gdb "\n"
|
|
|
|
gdb_test_multiple "" "discard newline" {
|
|
|
|
-re "^\r\n" {
|
gdb: fix for gdb.base/eof-exit.exp test failures
This fix relates to PR gdb/29032, this makes the test more stable by
ensuring that the Ctrl-D is only sent once the prompt has been
displayed. This issue was also discussed on the mailing list here:
https://sourceware.org/pipermail/gdb-patches/2022-April/187670.html
The problem identified in the bug report is that sometimes the Ctrl-D
(that the test sends to GDB) arrives while GDB is processing a
command. When this happens the Ctrl-D is handled differently than if
the Ctrl-D is sent while GDB is waiting for input at a prompt.
The original intent of the test was that the Ctrl-D be sent while GDB
was waiting at a prompt, and that is the case the occurs most often,
but, when the Ctrl-D arrives during command processing, then GDB will
ignore the Ctrl-D, and the test will fail.
This commit ensures the Ctrl-D is always sent while GDB is waiting at
a prompt, which makes this test stable.
But, that still leaves an open question, what should happen when the
Ctrl-D arrives while GDB is processing a command? This commit doesn't
attempt to answer that question, which is while bug PR gdb/29032 will
not be closed once this commit is merged.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29032
2022-04-20 21:08:49 +08:00
|
|
|
exp_continue
|
|
|
|
}
|
|
|
|
-notransfer -re "^\[^\n\]*$::gdb_prompt $" {
|
gdb: work around prompt corruption caused by bracketed-paste-mode
In this commit:
commit b4f26d541aa7224b70d363932e816e6e1a857633
Date: Tue Mar 2 13:42:37 2021 -0700
Import GNU Readline 8.1
We imported readline 8.1 into GDB. As a consequence bug PR cli/28833
was reported. This bug spotted that, when the user terminated GDB by
sending EOF (usually bound to Ctrl+d), the last prompt would become
corrupted. Here's what happens, the user is sat at a prompt like
this:
(gdb)
And then the user sends EOF (Ctrl+d), we now see this:
quit)
... gdb terminates, and we return to the shell ...
Notice the 'quit' was printed over the prompt.
This problem is a result of readline 8.1 enabling bracketed paste mode
by default. This problem is present in readline 8.0 too, but in that
version of readline bracketed paste mode is off by default, so a user
will not see the bug unless they specifically enable the feature.
Bracketed paste mode is available in readline 7.0 too, but the bug
is not present in this version of readline, see below for why.
What causes this problem is how readline disables bracketed paste
mode. Bracketed paste mode is a terminal feature that is enabled and
disabled by readline emitting a specific escape sequence. The problem
for GDB is that the escape sequence to disable bracketed paste mode
includes a '\r' character at the end, see this thread for more
details:
https://lists.gnu.org/archive/html/bug-bash/2018-01/msg00097.html
The change to add the '\r' character to the escape sequence used to
disable bracketed paste mode was introduced between readline 7.0 and
readline 8.0, this is why the bug would not occur when using older
versions of readline (note: I don't know if its even possible to build
GDB using readline 7.0. That really isn't important, I'm just
documenting the history of this issue).
So, the escape sequence to disable bracketed paste mode is emitted
from the readline function rl_deprep_terminal, this is called after
the user has entered a complete command and pressed return, or, if the
user sends EOF.
However, these two cases are slightly different. In the first case,
when the user has entered a command and pressed return, the cursor
will have moved to the next, empty, line, before readline emits the
escape sequence to leave bracketed paste mode. The final '\r'
character moves the cursor back to the beginning of this empty line,
which is harmless.
For the EOF case though, this is not what happens. Instead, the
escape sequence to leave bracketed paste mode is emitted on the same
line as the prompt. The final '\r' moves the cursor back to the start
of the prompt line. This leaves us ready to override the prompt.
It is worth noting, that this is not the intended behaviour of
readline, in rl_deprep_terminal, readline should emit a '\n' character
when EOF is seen. However, due to a bug in readline this does not
happen (the _rl_eof_found flag is never set). This is the first
readline bug that effects GDB.
GDB prints the 'quit' message from command_line_handler (in
event-top.c), this function is called (indirectly) from readline to
process the complete command line, but also in the EOF case (in which
case the command line is set to nullptr). As this is part of the
callback to process a complete command, this is called after readline
has disabled bracketed paste mode (by calling rl_deprep_terminal).
And so, when bracketed paste mode is in use, rl_deprep_terminal leaves
the cursor at the start of the prompt line (in the EOF case), and
command_line_handler then prints 'quit', which overwrites the prompt.
The solution to this problem is to print the 'quit' message earlier,
before rl_deprep_terminal is called. This is easy to do by using the
rl_deprep_term_function hook. It is this hook that usually calls
rl_deprep_terminal, however, if we replace this with a new function,
we can print the 'quit' string, and then call rl_deprep_terminal
ourselves. This allows the 'quit' to be printed before
rl_deprep_terminal is called.
The problem here is that there is no way in rl_deprep_terminal to know
if readline is processing EOF or not, and as a result, we don't know
when we should print 'quit'. This is the second readline bug that
effects GDB.
Both of these readline issues are discussed in this thread:
https://lists.gnu.org/archive/html/bug-readline/2022-02/msg00021.html
The result of that thread was that readline was patched to address
both of these issues.
Now it should be easy to backport the readline fix to GDB's in tree
copy of readline, and then change GDB to make use of these fixes to
correctly print the 'quit' string.
However, we are just about to branch GDB 12, and there is concern from
some that changing readline this close to a new release is a risky
idea, see this thread:
https://sourceware.org/pipermail/gdb-patches/2022-March/186391.html
So, this commit doesn't change readline at all. Instead, this commit
is the smallest possible GDB change in order to avoid the prompt
corruption.
In this commit I change GDB to print the 'quit' string on the line
after the prompt, but only when bracketed paste mode is on. This
avoids the overwriting issue, the user sees this:
(gdb)
quit
... gdb terminates, and returns to the shell ...
This isn't ideal, but is better than the existing behaviour. After
GDB 12 has branched, we can backport the readline fix, and apply a
real fix to GDB.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28833
2022-03-11 22:44:03 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
# Send GDB a ctrl-d. Check that we see the 'quit' string in the
|
|
|
|
# expected place.
|
|
|
|
send_gdb "\004"
|
|
|
|
gdb_test_multiple "" "close GDB with eof" {
|
|
|
|
-re "$::gdb_prompt \[^\n\]*\r\[^\n\]*quit" {
|
|
|
|
fail "$gdb_test_name (misplaced \\r)"
|
|
|
|
}
|
gdb/testsuite: fix test failure when building against readline v7
The test added in the commit:
commit a6b413d24ccc5d76179bab866834e11fd6fec294
Date: Fri Mar 11 14:44:03 2022 +0000
gdb: work around prompt corruption caused by bracketed-paste-mode
Was not written with readline 7 in mind, only readline 8+. Between
readline 7 and 8 the escape sequence used to disable bracketed paste
mode changed, an additional '\r' character was added to the end. In
fact, it was the addition of this '\r' character that triggered the
issue for which the above commit is part of the solution.
Anyway, the test tries to spot the case where the output from GDB is
not perfect, but does have the above work around applied. However,
the pattern in the test assumes that the problematic '\r' will be
present, and this is only true for readline 8+. With readline 7 the
test was failing.
In this commit I generalise the pattern a little so that the test will
still KFAIL with readline 7.
It's a little unfortunate that the test is KFAILing with readline 7,
as without the problematic '\r' there's actually no reason that GDB
couldn't "do the right thing" in this case, in which case, the test
would PASS, but that would require changes within GDB itself.
My preference then is that initially we patch the test to get it
KFAILing, then in a separate commit I can modify GDB so that it can
PASS with readline 7.
2022-03-26 21:41:33 +08:00
|
|
|
-re "$::gdb_prompt (?:\[^\n\]*\r)?\[^\n\]*\r\nquit\r\n" {
|
gdb: work around prompt corruption caused by bracketed-paste-mode
In this commit:
commit b4f26d541aa7224b70d363932e816e6e1a857633
Date: Tue Mar 2 13:42:37 2021 -0700
Import GNU Readline 8.1
We imported readline 8.1 into GDB. As a consequence bug PR cli/28833
was reported. This bug spotted that, when the user terminated GDB by
sending EOF (usually bound to Ctrl+d), the last prompt would become
corrupted. Here's what happens, the user is sat at a prompt like
this:
(gdb)
And then the user sends EOF (Ctrl+d), we now see this:
quit)
... gdb terminates, and we return to the shell ...
Notice the 'quit' was printed over the prompt.
This problem is a result of readline 8.1 enabling bracketed paste mode
by default. This problem is present in readline 8.0 too, but in that
version of readline bracketed paste mode is off by default, so a user
will not see the bug unless they specifically enable the feature.
Bracketed paste mode is available in readline 7.0 too, but the bug
is not present in this version of readline, see below for why.
What causes this problem is how readline disables bracketed paste
mode. Bracketed paste mode is a terminal feature that is enabled and
disabled by readline emitting a specific escape sequence. The problem
for GDB is that the escape sequence to disable bracketed paste mode
includes a '\r' character at the end, see this thread for more
details:
https://lists.gnu.org/archive/html/bug-bash/2018-01/msg00097.html
The change to add the '\r' character to the escape sequence used to
disable bracketed paste mode was introduced between readline 7.0 and
readline 8.0, this is why the bug would not occur when using older
versions of readline (note: I don't know if its even possible to build
GDB using readline 7.0. That really isn't important, I'm just
documenting the history of this issue).
So, the escape sequence to disable bracketed paste mode is emitted
from the readline function rl_deprep_terminal, this is called after
the user has entered a complete command and pressed return, or, if the
user sends EOF.
However, these two cases are slightly different. In the first case,
when the user has entered a command and pressed return, the cursor
will have moved to the next, empty, line, before readline emits the
escape sequence to leave bracketed paste mode. The final '\r'
character moves the cursor back to the beginning of this empty line,
which is harmless.
For the EOF case though, this is not what happens. Instead, the
escape sequence to leave bracketed paste mode is emitted on the same
line as the prompt. The final '\r' moves the cursor back to the start
of the prompt line. This leaves us ready to override the prompt.
It is worth noting, that this is not the intended behaviour of
readline, in rl_deprep_terminal, readline should emit a '\n' character
when EOF is seen. However, due to a bug in readline this does not
happen (the _rl_eof_found flag is never set). This is the first
readline bug that effects GDB.
GDB prints the 'quit' message from command_line_handler (in
event-top.c), this function is called (indirectly) from readline to
process the complete command line, but also in the EOF case (in which
case the command line is set to nullptr). As this is part of the
callback to process a complete command, this is called after readline
has disabled bracketed paste mode (by calling rl_deprep_terminal).
And so, when bracketed paste mode is in use, rl_deprep_terminal leaves
the cursor at the start of the prompt line (in the EOF case), and
command_line_handler then prints 'quit', which overwrites the prompt.
The solution to this problem is to print the 'quit' message earlier,
before rl_deprep_terminal is called. This is easy to do by using the
rl_deprep_term_function hook. It is this hook that usually calls
rl_deprep_terminal, however, if we replace this with a new function,
we can print the 'quit' string, and then call rl_deprep_terminal
ourselves. This allows the 'quit' to be printed before
rl_deprep_terminal is called.
The problem here is that there is no way in rl_deprep_terminal to know
if readline is processing EOF or not, and as a result, we don't know
when we should print 'quit'. This is the second readline bug that
effects GDB.
Both of these readline issues are discussed in this thread:
https://lists.gnu.org/archive/html/bug-readline/2022-02/msg00021.html
The result of that thread was that readline was patched to address
both of these issues.
Now it should be easy to backport the readline fix to GDB's in tree
copy of readline, and then change GDB to make use of these fixes to
correctly print the 'quit' string.
However, we are just about to branch GDB 12, and there is concern from
some that changing readline this close to a new release is a risky
idea, see this thread:
https://sourceware.org/pipermail/gdb-patches/2022-March/186391.html
So, this commit doesn't change readline at all. Instead, this commit
is the smallest possible GDB change in order to avoid the prompt
corruption.
In this commit I change GDB to print the 'quit' string on the line
after the prompt, but only when bracketed paste mode is on. This
avoids the overwriting issue, the user sees this:
(gdb)
quit
... gdb terminates, and returns to the shell ...
This isn't ideal, but is better than the existing behaviour. After
GDB 12 has branched, we can backport the readline fix, and apply a
real fix to GDB.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28833
2022-03-11 22:44:03 +08:00
|
|
|
# For versions of readline that don't include the
|
|
|
|
# RL_STATE_EOF patch, then the 'quit' is printed on the
|
|
|
|
# subsequent line.
|
|
|
|
kfail gdb/28833 "$gdb_test_name (older version of readline)"
|
|
|
|
}
|
|
|
|
-re "$::gdb_prompt quit\[^\n\]*\r\n\[^\n\]*\r\n$" {
|
|
|
|
# There was a bug where GDB would print an extra blank
|
|
|
|
# line after the 'quit', this catches that case.
|
|
|
|
fail $gdb_test_name
|
|
|
|
}
|
gdb: improved EOF handling when using readline 7
In this commit:
commit a6b413d24ccc5d76179bab866834e11fd6fec294
Date: Fri Mar 11 14:44:03 2022 +0000
gdb: work around prompt corruption caused by bracketed-paste-mode
a change was made to GDB to work around bug PR gdb/28833. The
consequence of this work around is that, when bracketed paste mode is
enabled in readline, and GDB is quit by sending EOF, then the output
will look like this:
(gdb)
quit
The ideal output, which is what we get when bracketed paste mode is
off, is this:
(gdb) quit
The reason we need to make this change is explained in the original
commit referenced above. What isn't mentioned in the above commit, is
that the change that motivated this work around was only added in
readline 8, older versions of readline don't require the change.
In later commits in this series I will add a fix to GDB's in-tree copy
of readline (this fix is back-ported from upstream readline), and then
I will change GDB so that, when using the (patched) in-tree readline,
we can have the ideal output in all cases.
However, GDB can be built against the system readline. When this is
done, and the system readline is version 8, then we will still have to
use the work around (two line) style output.
But, if GDB is built against the system readline, and the system
readline is an older version 7 readline, then there's no reason why we
can't have the ideal output, after all, readline 7 doesn't include the
change that we need to work around.
This commit changes GDB so that, when using readline 7 we get the
ideal output in all cases. This change is trivial (a simple check
against the readline version number) so I think this should be fine to
include.
For testing this commit, you need to configure GDB including the
'--with-system-readline' flag, and build GDB on a system that uses
readline 7, for example 'Ubuntu 18.04'. Then run the test
'gdb.base/eof-exit.exp', you should expect everything to PASS.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28833
2022-03-29 22:07:04 +08:00
|
|
|
-re "$::gdb_prompt \[^\n\r\]*quit\[^\n\]*\r\n\[^\n\]*$" {
|
gdb: work around prompt corruption caused by bracketed-paste-mode
In this commit:
commit b4f26d541aa7224b70d363932e816e6e1a857633
Date: Tue Mar 2 13:42:37 2021 -0700
Import GNU Readline 8.1
We imported readline 8.1 into GDB. As a consequence bug PR cli/28833
was reported. This bug spotted that, when the user terminated GDB by
sending EOF (usually bound to Ctrl+d), the last prompt would become
corrupted. Here's what happens, the user is sat at a prompt like
this:
(gdb)
And then the user sends EOF (Ctrl+d), we now see this:
quit)
... gdb terminates, and we return to the shell ...
Notice the 'quit' was printed over the prompt.
This problem is a result of readline 8.1 enabling bracketed paste mode
by default. This problem is present in readline 8.0 too, but in that
version of readline bracketed paste mode is off by default, so a user
will not see the bug unless they specifically enable the feature.
Bracketed paste mode is available in readline 7.0 too, but the bug
is not present in this version of readline, see below for why.
What causes this problem is how readline disables bracketed paste
mode. Bracketed paste mode is a terminal feature that is enabled and
disabled by readline emitting a specific escape sequence. The problem
for GDB is that the escape sequence to disable bracketed paste mode
includes a '\r' character at the end, see this thread for more
details:
https://lists.gnu.org/archive/html/bug-bash/2018-01/msg00097.html
The change to add the '\r' character to the escape sequence used to
disable bracketed paste mode was introduced between readline 7.0 and
readline 8.0, this is why the bug would not occur when using older
versions of readline (note: I don't know if its even possible to build
GDB using readline 7.0. That really isn't important, I'm just
documenting the history of this issue).
So, the escape sequence to disable bracketed paste mode is emitted
from the readline function rl_deprep_terminal, this is called after
the user has entered a complete command and pressed return, or, if the
user sends EOF.
However, these two cases are slightly different. In the first case,
when the user has entered a command and pressed return, the cursor
will have moved to the next, empty, line, before readline emits the
escape sequence to leave bracketed paste mode. The final '\r'
character moves the cursor back to the beginning of this empty line,
which is harmless.
For the EOF case though, this is not what happens. Instead, the
escape sequence to leave bracketed paste mode is emitted on the same
line as the prompt. The final '\r' moves the cursor back to the start
of the prompt line. This leaves us ready to override the prompt.
It is worth noting, that this is not the intended behaviour of
readline, in rl_deprep_terminal, readline should emit a '\n' character
when EOF is seen. However, due to a bug in readline this does not
happen (the _rl_eof_found flag is never set). This is the first
readline bug that effects GDB.
GDB prints the 'quit' message from command_line_handler (in
event-top.c), this function is called (indirectly) from readline to
process the complete command line, but also in the EOF case (in which
case the command line is set to nullptr). As this is part of the
callback to process a complete command, this is called after readline
has disabled bracketed paste mode (by calling rl_deprep_terminal).
And so, when bracketed paste mode is in use, rl_deprep_terminal leaves
the cursor at the start of the prompt line (in the EOF case), and
command_line_handler then prints 'quit', which overwrites the prompt.
The solution to this problem is to print the 'quit' message earlier,
before rl_deprep_terminal is called. This is easy to do by using the
rl_deprep_term_function hook. It is this hook that usually calls
rl_deprep_terminal, however, if we replace this with a new function,
we can print the 'quit' string, and then call rl_deprep_terminal
ourselves. This allows the 'quit' to be printed before
rl_deprep_terminal is called.
The problem here is that there is no way in rl_deprep_terminal to know
if readline is processing EOF or not, and as a result, we don't know
when we should print 'quit'. This is the second readline bug that
effects GDB.
Both of these readline issues are discussed in this thread:
https://lists.gnu.org/archive/html/bug-readline/2022-02/msg00021.html
The result of that thread was that readline was patched to address
both of these issues.
Now it should be easy to backport the readline fix to GDB's in tree
copy of readline, and then change GDB to make use of these fixes to
correctly print the 'quit' string.
However, we are just about to branch GDB 12, and there is concern from
some that changing readline this close to a new release is a risky
idea, see this thread:
https://sourceware.org/pipermail/gdb-patches/2022-March/186391.html
So, this commit doesn't change readline at all. Instead, this commit
is the smallest possible GDB change in order to avoid the prompt
corruption.
In this commit I change GDB to print the 'quit' string on the line
after the prompt, but only when bracketed paste mode is on. This
avoids the overwriting issue, the user sees this:
(gdb)
quit
... gdb terminates, and returns to the shell ...
This isn't ideal, but is better than the existing behaviour. After
GDB 12 has branched, we can backport the readline fix, and apply a
real fix to GDB.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28833
2022-03-11 22:44:03 +08:00
|
|
|
pass $gdb_test_name
|
|
|
|
}
|
|
|
|
eof {
|
|
|
|
fail "$gdb_test_name (missed the prompt)"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
with_test_prefix "default" {
|
|
|
|
run_test
|
|
|
|
}
|
|
|
|
|
|
|
|
save_vars { env(TERM) } {
|
|
|
|
setenv TERM ansi
|
|
|
|
|
|
|
|
with_test_prefix "with non-dump terminal" {
|
|
|
|
run_test
|
|
|
|
|
|
|
|
save_vars { env(INPUTRC) } {
|
|
|
|
|
|
|
|
# Create an inputrc file that turns bracketed paste mode
|
|
|
|
# on. This is usually turned off (see lib/gdb.exp), but
|
|
|
|
# for the next test we want to see what happens with this
|
|
|
|
# on.
|
|
|
|
set inputrc [standard_output_file inputrc]
|
|
|
|
set fd [open "$inputrc" w]
|
|
|
|
puts $fd "set enable-bracketed-paste on"
|
|
|
|
close $fd
|
|
|
|
|
|
|
|
setenv INPUTRC "$inputrc"
|
|
|
|
with_test_prefix "with bracketed-paste-mode on" {
|
|
|
|
run_test
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|