Some psABIs define a relaxation to turn a GOT load into a PC-relative
address materialization. For example, the AArch64's psABI allows
adrp+ldr to be rewritten to nop+adr to eliminate the memory load.
This patch is part of the effort to make such optimization possible
for RISC-V.
For RISC-V, we use the la assembly pseudo instruction to load a symbol
address from the GOT. The pseudo instruction is expanded to auipc+ld.
If the address loaded by the instruction pair is actually a PC-relative
link-time constant, we want the linker to rewrite the instruction pair
with auipc+addi.
We can't rewrite all existing auipc+ld pairs with auipc+addi in the
linker because there might be code that jumps to the middle of the
instruction pair. That should be extremely rare, if ever exists, but
you can at least in theory write a program in assembly that jumps to
the ld instruction of the instruction pair. We need a marker to
identify that an auipc+ld can be safely relaxed (i.e. they are emitted
for la).
This patch is to annotate R_RISCV_GOT_HI20 with R_RISCV_RELAX only
when the relocation is emitted for the la pseudo instruction. The
linker will use it as a signal that the instruction pair can be safely
relaxed.
Proposal to the RISC-V psABI:
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/397
gas/
* config/tc-riscv.c (source_macro): New static int variable.
The identifier of the assembler macro we are expanding, if any.
(append_insn): Updated source_macro to tc_fix_data, to record
which macro expands, if any.
(macro): Record which macro expands into source_macro. Reset
source_macro to -1 at the end.
(md_apply_fix): Apply R_RISCV_RELAX if pcrel_got_hi is expanded
from macro LA/LGA.
* config/tc-riscv.h (struct riscv_fix, TC_FIX_TYPE, TC_INIT_FIX_DATA):
Defined to record source_macro into fixups for riscv target.
* testsuite/gas/riscv/la-variants.d: Updated.
In the scenario of generating .ko files, the kernel does not relax the .ko
files. However, due to the large amount of relax and local relocation
information, this increases the size of the .ko files. In this patch, it
will finish the fixup of the local relocations while with `-mno-relax' option.
This can reduce the size of the relocation table.
The implemntation is based on the code from bfd/elfnn-riscv.c. We probably
can move the code to bfd/elfxx-riscv.c, so that can reduce duplicate code,
just like what we did for the architecture parser.
Besides, maybe not only pcrel_hi/lo12 relocation with local symbols can be
resolved at assembler time. Other pc-relative relocation, like branch,
may also be able to perform related optimizations.
Passed the gcc/binutils regressions of riscv-gnu-toolchain.
gas/
* config/tc-riscv.c (riscv_pcrel_hi_reloc): New structure. Record all
PC-relative high-part relocation that we have encountered to help us
resolve the corresponding low-part relocation later.
(riscv_pcrel_hi_fixup_hash): The hash table to record pcrel_hi fixups.
(riscv_pcrel_fixup_hash): New function. Likewise.
(riscv_pcrel_fixup_eq): Likewise.
(riscv_record_pcrel_fixup): Likewise.
(md_begin): Init pcrel_hi hash table.
(md_apply_fix): For PCREL_HI20 relocation, do fixup and record
the pcrel_hi relocs, mark as done while with `-mno-relax'. For
PCREL_LO12_I/S relocation, do fixup and mark as done while with
`-mno-relax'.
(riscv_md_end): New function. Free pcrel_hi hash table.
* config/tc-riscv.h (md_end): Define md_end with riscv_md_end.
gas/
* testsuite/gas/riscv/fixup-local*: New tests.
This implements DAP cancellation. A new object is introduced that
handles the details of cancellation. While cancellation is inherently
racy, this code attempts to make it so that gdb doesn't inadvertently
cancel the wrong request.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30472
Approved-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
Cancellation will generally be seen by the DAP code as a
KeyboardInterrupt. However, this derives from BaseException and not
Exception, so a small change is needed to send_gdb_with_response, to
forward the exception to the DAP server thread.
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
This renames a couple of DAP procs in the testsuite, to clarify that
they are now exported. The cancellation test will need these.
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
DAP cancellation needs a way to interrupt whatever is happening on
gdb's main thread -- whether that is the inferior, a gdb CLI command,
or Python code.
This patch adds a new gdb.interrupt() function for this purpose. It
simply sets the quit flag and lets gdb do the rest.
No tests in this patch -- instead this is tested via the DAP
cancellation tests.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
This changes the DAP server to move the JSON reader to a new thread.
This is key to implementing request cancellation, as now requests can
be read while an earlier one is being serviced.
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
This patch introduces a new NotStoppedException type and changes the
DAP implementation of "not stopped" to use it. I was already touching
some code in this area and I thought this looked a little cleaner.
This also has the advantage that we can now choose not to log the
exception -- previously I was sometimes a bit alarmed when seeing this
in the logs, even though it is harmless.
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
Now that gdb adds stop-reason details to stop events, we can simplify
the DAP code to emit correct stop reasons in its own events. For the
most part a simple renaming of gdb reasons is sufficient; however,
"pause" must still be handled specially.
This changes Python stop events to carry a "details" dictionary, that
holds any relevant information about the stop. The details are
constructed using more or less the same procedure as is done for MI.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13587
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Commit cff71358132 ("gdb/testsuite: tighten up some end-of-line patterns") replaced:
...
set eol "\[\r\n\]+"
...
with the more strict:
...
set eol "\r\n"
...
in a few test-cases, but didn't update all uses of eol accordingly.
Fix this in three gdb.ada test-cases.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
I found some spots using "target:"; I think it's better to use the
define everywhere, so this changes these to use TARGET_SYSROOT_PREFIX.
In some spots, is_target_filename is used rather than an explicit
check.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Now that DAP is in GDB 14, significant changes to it should be noted
in NEWS. This patch adds a note for a fix that's already gone in. I
started a new section in NEWS because more changes are coming.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30473
Approved-By: Eli Zaretskii <eliz@gnu.org>
PR29011 notes that dynamic_cast does not work correctly if
classes with virtual methods are involved, some of the results
wrongly point into the vtable of the derived class:
```
(gdb) p vlr
$1 = (VirtualLeftRight *) 0x162240
(gdb) p vl
$2 = (VirtualLeft *) 0x162240
(gdb) p vr
$3 = (VirtualRight *) 0x162250
(gdb) p dynamic_cast<VirtualLeftRight*>(vlr)
$4 = (VirtualLeftRight *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
(gdb) p dynamic_cast<VirtualLeftRight*>(vl)
$5 = (VirtualLeftRight *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
(gdb) p dynamic_cast<VirtualLeftRight*>(vr)
$6 = (VirtualLeftRight *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
(gdb) p dynamic_cast<VirtualLeft*>(vlr)
$7 = (VirtualLeft *) 0x162240
(gdb) p dynamic_cast<VirtualLeft*>(vl)
$8 = (VirtualLeft *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
(gdb) p dynamic_cast<VirtualLeft*>(vr)
$9 = (VirtualLeft *) 0x162240
(gdb) p dynamic_cast<VirtualRight*>(vlr)
$10 = (VirtualRight *) 0x162250
(gdb) p dynamic_cast<VirtualRight*>(vl)
$11 = (VirtualRight *) 0x162250
(gdb) p dynamic_cast<VirtualRight*>(vr)
$12 = (VirtualRight *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
```
For the cases where the dynamic_cast type is the same as the
original type, it used the ARG value for the result, which in
case of pointer types was already the dereferenced value.
And the TEM value at the value address was created with the
pointer/reference type, not the actual class type.
With these fixed, the dynamic_cast results make more sense:
```
(gdb) p vlr
$1 = (VirtualLeftRight *) 0x692240
(gdb) p vl
$2 = (VirtualLeft *) 0x692240
(gdb) p vr
$3 = (VirtualRight *) 0x692250
(gdb) p dynamic_cast<VirtualLeftRight*>(vlr)
$4 = (VirtualLeftRight *) 0x692240
(gdb) p dynamic_cast<VirtualLeftRight*>(vl)
$5 = (VirtualLeftRight *) 0x692240
(gdb) p dynamic_cast<VirtualLeftRight*>(vr)
$6 = (VirtualLeftRight *) 0x692240
(gdb) p dynamic_cast<VirtualLeft*>(vlr)
$7 = (VirtualLeft *) 0x692240
(gdb) p dynamic_cast<VirtualLeft*>(vl)
$8 = (VirtualLeft *) 0x692240
(gdb) p dynamic_cast<VirtualLeft*>(vr)
$9 = (VirtualLeft *) 0x692240
(gdb) p dynamic_cast<VirtualRight*>(vlr)
$10 = (VirtualRight *) 0x692250
(gdb) p dynamic_cast<VirtualRight*>(vl)
$11 = (VirtualRight *) 0x692250
(gdb) p dynamic_cast<VirtualRight*>(vr)
$12 = (VirtualRight *) 0x692250
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29011
Approved-By: Tom Tromey <tom@tromey.com>
The `relaxable' in md_apply_fix means if the relocation can be relaxed or not
in link-time generally. We can use `.option relax/norelax' to enable/disable
relaxations for some specific areas, so the value of `riscv_opts.relax'
will be changed dynamically. The `fixP->fx_tcbit' records the correct value
of `riscv_opts.relax' for every relocation. Therefore, set `relaxable' to
`riscv_opts.relax' will cause unexpected behavior for the following case,
.option norelax
lla a1, foo1
.option relax
lla a2, foo2
.option norelax
lla a3, foo3
For the current assembler, the final value of `riscv_opts.relax' is false, so
the second `lla a2, foo2' won't have R_RISCV_RELAX relocation, but should have.
gas/
* config/tc-riscv.c (md_apply_fix): Set the value of `relaxable' to
`riscv_opts.relax' is wrong. It should be `true' generally.
This reloc is meant for the 16-bit LWGP instruction, 0x6400/0xfc00
match/mask encoding in `micromips_opcodes'. It is correctly specified
to operate on a half-word by the howtos in elf32-mips.c, elfn32-mips.c
and elf64-mips.c, but is incorrectly subject to shuffle/unshuffle in
code like _bfd_mips_elf32_gprel16_reloc.
Current behaviour when applying the reloc to .byte 0x11,0x22,0x33,0x44
is to apply the reloc to byte 0x22 when big-endian, and to byte 0x33
when little-endian. Big-endian behaviour is unchanged after this
patch and little-endian correctly applies the reloc to byte 0x11.
The patch also corrects REL addend extraction from section contents,
and overflow checking. gold had all of the bfd problems with this
reloc and additionally did not apply the rightshift by two.
bfd/
* elfxx-mips.c (micromips_reloc_shuffle_p): Return false for
R_MICROMIPS_GPREL7_S2.
(mips_elf_calculate_relocation): Correct sign extension and
overflow calculation for R_MICROMIPS_GPREL7_S2.
(_bfd_mips_elf_relocate_section): Update small-data overflow
message.
gold/
* mips.cc (Mips_relocate_functions::should_shuffle_micromips_reloc):
Return false for R_MICROMIPS_GPREL7_S2.
(Mips_relocate_functions::mips_reloc_unshuffle): Update comment.
(Mips_relocate_functions::relgprel): Remove R_MICROMIPS_GPREL7_S2
handling.
(Mips_relocate_functions::relgprel7): New function.
(Target_mips::Relocate::relocate): Adjust to suit.
ld/
* testsuite/ld-mips-elf/reloc-4.d: Adjust expected error.
* testsuite/ld-mips-elf/reloc-5.d: Likewise.
I've reimplemented the .debug_names code in GDB -- it was quite far
from being correct, and the new implementation is much closer to what
is specified by DWARF.
However, the new writer in GDB needs to emit some symbol properties,
so that the reader can be fully functional. This patch adds a few new
DW_IDX_* constants, and tries to document the existing extensions as
well. (My patch series add more documentation of these to the GDB
manual as well.)
2023-12-10 Tom Tromey <tom@tromey.com>
* dwarf2.def (DW_IDX_GNU_internal, DW_IDX_GNU_external): Comment.
(DW_IDX_GNU_main, DW_IDX_GNU_language, DW_IDX_GNU_linkage_name):
New constants.
Running the H8 port through the GCC testsuite currently takes 4h 30m on my
fastest server -- that's roughly 1.5hrs per multilib tested and many tests are
disabled for various reasons.
To put that 1.5hr/multilib in perspective, that's roughly 3X the time for other
embedded targets. Clearly something isn't working as well as it should.
A bit of digging with perf shows that we're spending a crazy amount of time
decoding instructions in the H8 simulator. It's not hard to see why --
basically we take a blob of instruction data, then try to match it to every
instruction in the H8 opcode table starting at the beginning. That table has
~8000 entries (each different addressing mode is considered a different
instruction in the table).
Naturally my first thought was to sort the table and use a binary search to
find the right entry. That's made excessively complex due to the encoding on
the H8. Just getting the sort right would be much more complex than I'd
consider advisable.
Another thought was to build a mapping to the right entry for all the
instructions that can be disambiguated based on the first nibble (4 bits) of
instruction data and a mapping for those which can be disambiguated based on
the first byte of instruction data.
That seemed feasible until I realized that the H8/SX did some truly horrid
things with encoding branches in the 0x4XYY opcode space. It uses an "always
zero" bit in the offset to encode new semantic information. So we can't select
on just 0x4X. Ugh!
We could always to a custom decoder. I've done several through the years, they
can be very fast. But no way I can justify the time to do that.
So what I settled on was to first sort the opcode table by the first nibble,
then find the index of the first instruction for each nibble. Decoding uses
that index to start its search. This cuts the overall build/test by more than
half.
Next I adjusted the sort so that instructions that are not available on the
current sub architecture are put at the end of the table. This shaves another
~15% off the total cycle time.
The net of the two changes is on my fastest server we've gone from 4:30 to 1:40
running the GCC testsuite. Same test results before/after, of course. It's
still not fast, but it's a hell of a lot better.
In tui_layout_split::apply I noticed that for variable-size layouts we take
share_box into account by decreasing used_size:
...
used_size += info[i].size;
if (info[i].share_box)
--used_size;
...
but not for fixed-size layouts:
...
if (info[i].min_size == info[i].max_size)
available_size -= info[i].min_size;
...
Fix this by increasing available_size for fixed-size layouts with shared box.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
The focused window is highlighted by using active-border-kind instead of
border-kind.
But if the focused window is the cmd window (which is an unboxed window), then
no highlighting is done, and it's not obvious from looking at the screen which
window has the focus. Instead, you have to notice the absence of highlighting
on boxed windows, and then infer that the focus is on the unboxed window.
That approach stops working if there are multiple unboxed windows.
Likewise if highlighting is switched off by setting active-border-kind to the
same value as border-kind.
Make it more explicit which window has the focus by mentioning it in the status
window, like so:
...
native process 8282 (src) In: main L7 PC: 0x400525
...
Tested on x86_64-linux and ppc64le-linux.
Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
Since 3c45e9f915ae4aeab7312d6fc55a947859057572 gdb crashes when trying
to print a global variable stub without a running inferior, because of
a missing nullptr-check (the block_scope function took care of that
check before it was converted to a method).
With this check it works again:
```
(gdb) print s
$1 = <incomplete type>
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31128
Approved-By: Tom Tromey <tom@tromey.com>
Following on from the previous commit, I searched the testsuite for
places where we did:
set eol "<some pattern>"
in most cases the <some pattern> could be replaced with "\r\n" though
in the stabs test I've switched to using the multi_line proc as that
seemed like a better choice.
In gdb.ada/info_types.exp I did need to add an extra use of $eol as
the previous pattern would match multiple newlines, and in this one
place we were actually expecting to match multiple newlines. The
tighter pattern only matches a single newline, so we now need to be
explicit when multiple newlines are expected -- I think this is a good
thing.
All the tests are still passing for me after these changes.
Approved-By: Tom Tromey <tom@tromey.com>
While reviewing another patch I spotted a timeout in
gdb.ada/complete.exp when testing in READ1 mode, e.g.:
$ make check-read1 TESTS="gdb.ada/complete.exp"
...
FAIL: gdb.ada/complete.exp: complete break ada (timeout)
...
The problem is an attempt to match the entire output from GDB within a
single gdb_test_multiple pattern, for a completion command that
returns a large number of completions.
This commit changes the gdb_test_multiple to process the output line
by line. I don't use the gdb_test_multiple -lbl option, as I've
always found that option backward -- it checks for the \r\n at the
start of each line rather than the end, I think it's much clearer to
use '^' at the start of each pattern, and '\r\n' at the end, so that's
what I've done here.
.... Or I would, if this test didn't already define $eol as the end of
line regexp ... except that $eol was set to '[\r\n]*', which isn't
that helpful, so I've updated $eol to be just '\r\n' the actual end of
line regexp.
And now, the test passes without a timeout when using READ1.
There should be no change in what is tested after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
Building on the last commit, which added a general --debug=COMPONENT
option to the gdbserver command line, this commit updates the monitor
command to allow for general:
(gdb) monitor set debug COMPONENT off|on
style commands. Just like with the previous commit, the COMPONENT can
be any one of all, threads, remote, event-loop, and correspond to the
same set of global debug flags.
While on the command line it is possible to do:
--debug=remote,event-loop,threads
the components have to be entered one at a time with the monitor
command. I guess there's no reason why we couldn't allow component
grouping within the monitor command, but (to me) what I have here
seemed more in the spirit of GDB's existing 'set debug ...' commands.
If people want it then we can always add component grouping later.
Notice in the above that I use 'off' and 'on' instead of '0' and '1',
which is what the 'monitor set debug' command used to use. The 0/1
can still be used, but I now advertise off/on in all the docs and help
text, again, this feels more inline with GDB's existing boolean
settings.
I have removed the two existing monitor commands:
monitor set remote-debug 0|1
monitor set event-loop-debug 0|1
These are replaced by:
monitor set debug remote off|on
monitor set debug event-loop off|on
respectively.
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Currently, gdbserver has the following command line options related to
debugging output:
--debug
--remote-debug
--event-loop-debug
This doesn't scale well. If I want an extra debug component I need to
add another command line flag.
This commit changes --debug to take a list of components.
The currently supported components are: all, threads, remote, and
event-loop. The 'threads' component represents the debug we currently
get from the --debug option. And if --debug is used without a
component list then the threads component is assumed as the default.
Currently the threads component actually includes a lot of output that
is not really threads related. In the future I'd like to split this
up into some new, separate components. But that is not part of this
commit, or even this series.
The special component 'all' does what you'd expect: enables debug
output from all supported components.
The component list is parsed left to write, and you can prefix a
component with '-' to disable that component, so I can write:
target> gdbserver --debug=all,-event-loop
to get debug for all components except the event-loop component.
I've removed the existing --remote-debug and --event-loop-debug
command line options, these are equivalent to --debug=remote and
--debug=event-loop respectively, or --debug=remote,event-loop to
enable both components.
In this commit I've only update the command line options, in the next
commit I'll update the monitor commands to support a similar
interface.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
The gdb/testsuite/README file documents GDB_DEBUG and GDBSERVER_DEBUG
flags, which can be passed to make in order to enable debugging within
GDB or gdbserver respectively.
However, when I do:
make check-gdb GDB_DEBUG=infrun
I don't see the corresponding debug feature within GDB being enabled.
Nor does:
make check-gdb GDBSERVER_DEBUG=debug \
RUNTESTFLAGS="--target_board=native-extended-gdbserver"
Appear to enable gdbserver debugging.
I tracked this down to the GDB_DEBUG and GDBSERVER_DEBUG flags being
missing from the TARGET_FLAGS_TO_PASS variable in gdb/Makefile. This
variable already contains lots of testing related flags, like
RUNTESTFLAGS and TESTS, so I think it makes sense to add GDB_DEBUG and
GDBSERVER_DEBUG here too.
With this done, this debug feature is now working as expected.
Approved-By: Tom Tromey <tom@tromey.com>
PR29079 shows that pretty printers can be used for an incomplete
type (stub), but only when printing it directly, not if it's
part of another struct:
```
(gdb) p s
$1 = {pp m_i = 5}
(gdb) p s2
$2 = {m_s = <incomplete type>, m_l = 20}
```
The reason is simply that in common_val_print the check for stubs
is before any pretty printer is tried.
It works if the pretty printer is tried before the stub check:
```
(gdb) p s
$1 = {pp m_i = 5}
(gdb) p s2
$2 = {m_s = {pp m_i = 10}, m_l = 20}
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29079
Approved-By: Tom Tromey <tom@tromey.com>
A TUI src window is displaying either:
- the source for the current frame,
- the source for main, or
- the string "[ No Source Available ]".
Since commit 03893ce67b5 ("[gdb/tui] Fix resizing of terminal to 1 or 2 lines")
we're able to resize the TUI to 1 line without crashing.
I noticed that if TUI is displaying main, and we resize to 1 line (destroying
the src window) and then back to a larger terminal (reconstructing the src
window), the TUI displays "[ No Source Available ]" instead of main.
Fix this by moving the responsibility for showing main from tui_enable to
tui_source_window_base::rerender.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR rust/31082 points out that casting a 128-bit integer to a pointer
will fail. This happens because a case in value_cast was not
converted to use GMP.
This patch fixes the problem. I am not really sure that testing
against the negative value here makes sense, but I opted to just
preserve the existing behavior rather than change it.
Regression tested on x86-64 Fedora 38.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31082
PR rust/31005 points out that dynamic type resolution of a LOC_CONST
or LOC_CONST_BYTES symbol will fail, leading to output like:
from_index=<error reading variable: Cannot access memory at address 0x0>
This patch fixes the problem by using the constant value or bytes when
performing type resolution.
Thanks to tpzker@thepuzzlemaker.info for a first version of this
patch.
I also tested this on a big-endian PPC system (cfarm203).
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31005
When examining a failure that happens when testing
gdb.python/py-symtab.c with clang, I noticed that it was going wrong
because the test assumed that whenever we get an SAL, its end would
always be right before statement in the line table. This is true for GCC
compiled binaries, since gcc only adds statements to the line table, but
not true for clang compiled binaries.
This is the second time I run into a problem where GDB doesn't handle
non-statement line table entries correctly. The other was eventually
committed as 9ab50efc463ff723b8e9102f1f68a6983d320517: "gdb: fix until
behavior with trailing !is_stmt lines", but that commit only changes the
behavior for the 'until' command. In this patch I propose a more general
solution, making it so every time we generate the SAL for a given pc, we
set the end of the SAL to before the next statement or the first
instruciton in the next line, instead of naively assuming that to be the
case.
With this new change, the edge case is removed from the processing of
the 'until' command without regressing the accompanying test case, and
no other regressions were observed in the testsuite.
Approved-By: Tom Tromey <tom@tromey.com>
