| Age | Commit message (Collapse) | Author |
|---|
|
Fixes:
CXX ser-mingw.o
/home/simark/src/binutils-gdb/gdb/ser-mingw.c: In function ‘int pipe_windows_open(serial*, const char*)’:
/home/simark/src/binutils-gdb/gdb/ser-mingw.c:870:3: error: ‘gdb_argv’ was not declared in this scope
870 | gdb_argv argv (name);
| ^~~~~~~~
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28802
Change-Id: I7f3e8ec5f9ca8582d587545fdf6b69901259f199
|
|
I noticed two places in the docs where we appear to be missing @r.
makeinfo seems to do the correct things despite these being
missing (at least, I couldn't see any difference in the pdf or info
output), but it doesn't hurt to have the @r in place.
|
|
We found a case where --gc-sections can cause gdb to set an invalid
breakpoint. In the included test case, gdb will set a breakpoint with
two locations, one of which is 0x0.
The code in lnp_state_machine::check_line_address is intended to
filter out this sort of problem, but in this case, the entire CU is
empty, causing unrelocated_lowpc==0x0 -- which circumvents the check.
It seems to me that if a CU is empty like this, then it is ok to
simply ignore the line table, as there won't be any locations anyway.
|
|
Add `set print array-indexes' tests for C/C++ arrays, complementing one
for Fortran arrays.
|
|
Add `set print array-indexes' handling for Fortran arrays. Currently
the setting is ignored and indices are never shown.
Keep track of the most recent index handled so that any outstanding
repeated elements printed when the limit set by `set print elements' is
hit have the correct index shown.
Output now looks like:
(gdb) set print array-indexes on
(gdb) print array_1d
$1 = ((-2) = 1, (-1) = 1, (0) = 1, (1) = 1, (2) = 1)
(gdb) set print repeats 4
(gdb) set print elements 12
(gdb) print array_2d
$2 = ((-2) = ((-2) = 2, <repeats 5 times>) (-1) = ((-2) = 2, <repeats 5 times>) (0) = ((-2) = 2, (-1) = 2, ...) ...)
(gdb)
for a 5-element vector and a 5 by 5 array filled with the value of 2.
|
|
Add `set print repeats' tests for C/C++ arrays, complementing one for
Fortran arrays and covering the different interpretation of the `set
print elements' setting in particular where the per-dimension count of
the elements handled is matched against the trigger rather than the
total element count as with Fortran arrays.
|
|
Implement `set print repeats' handling for Fortran arrays. Currently
the setting is ignored and always treated as if no limit was set.
Unlike the generic array walker implemented decades ago the Fortran one
is a proper C++ class. Rather than trying to mimic the old walker then,
which turned out a bit of a challenge where interacting with the `set
print elements' setting, write it entirely from scratch, by adding an
extra specialization handler method for processing dimensions other than
the innermost one and letting the specialization class call the `walk_1'
method from the handler as it sees fit. This way repeats can be tracked
and the next inner dimension recursed into as a need arises only, or
unconditionally in the base class.
Keep track of the dimension number being handled in the class rather as
a parameter to the walker so that it does not have to be passed across
by the specialization class.
Use per-dimension element count tracking, needed to terminate processing
early when the limit set by `set print elements' is hit. This requires
extra care too where the limit triggers exactly where another element
that is a subarray begins. In that case rather than recursing we need
to terminate processing or lone `(...)' would be printed. Additionally
if the skipped element is the last one in the current dimension we need
to print `...' by hand, because `continue_walking' won't print it at the
upper level, because it can see the last element has already been taken
care of.
Preserve the existing semantics of `set print elements' where the total
count of the elements handled is matched against the trigger level which
is unlike with the C/C++ array printer where the per-dimension element
count is used instead.
Output now looks like:
(gdb) set print repeats 4
(gdb) print array_2d
$1 = ((2, <repeats 5 times>) <repeats 5 times>)
(gdb) set print elements 12
(gdb) print array_2d
$2 = ((2, <repeats 5 times>) (2, <repeats 5 times>) (2, 2, ...) ...)
(gdb)
for a 5 by 5 array filled with the value of 2.
Amend existing test cases accordingly that rely on the current incorrect
behavior and explicitly request that there be no limit for printing
repeated elements there.
Add suitable test cases as well covering sliced arrays in particular.
Co-Authored-By: Andrew Burgess <andrew.burgess@embecosm.com>
|
|
|
|
My earlier patch to move gdb_argv broke the remote-sim.c build. This
patch fixes the bug. I'm checking it in.
|
|
All the Ada catchpoints use the same breakpoint_ops contents, because
the catchpoint itself records its kind. This patch simplifies the
code by removing the redundant ops structures.
|
|
The "catch exec" code is reasonably self-contained, and so this patch
moves it out of breakpoint.c (the second largest source file in gdb)
and into a new file, break-catch-exec.c.
|
|
The "catch fork" code is reasonably self-contained, and so this patch
moves it out of breakpoint.c (the second largest source file in gdb)
and into a new file, break-catch-fork.c.
|
|
I noticed that "catch fork" and "catch vfork" are nearly identical.
This patch simplifies the code by unifying these two cases.
|
|
This moves the gdb_regex convenience class to gdbsupport.
|
|
gdb has some extensions and helpers for working with the libiberty
hash table. This patch consolidates these and moves them to
gdbsupport.
|
|
This moves the gdb-specific obstack code -- both extensions like
obconcat and obstack_strdup, and things like auto_obstack -- to
gdbsupport.
|
|
This moves the gdb_argv class to a new header in gdbsupport.
|
|
event_location_probe currently stores two strings, but really only
needs one. This patch simplifies it and removes some unnecessary
copies as well.
|
|
This changes event_location to use std::string, removing some manual
memory management, and an unnecessary string copy.
|
|
event_location uses the old C-style discriminated union approach.
However, it's better to use subclassing, as this makes the code
clearer and removes some chances for error. This also enables future
cleanups to avoid manual memory management and copies.
|
|
This patch removes the old-style EL_* macros from location.c. This
cleans up the code by itself, IMO, but also enables further cleanups
in subsequent patches.
|
|
This changes explicit_to_string_internal to use 'bool' rather than
'int'.
|
|
This small cleanup removes a use of xfree from location.c, by
switching to unique_xmalloc_ptr. One function is only used in
location.c, so it is made static. And, another function is changed to
avoid a copy.
|
|
Same idea as 0fab79556484 ("gdb: use ptid_t::to_string in infrun debug
messages"), but throughout GDB.
Change-Id: I62ba36eaef29935316d7187b9b13d7b88491acc1
|
|
Consider this GDB session:
$ gdb -q
(gdb) target remote | gdbserver - ~/tmp/hello.x
Remote debugging using | gdbserver - ~/tmp/hello.x
... snip ...
(gdb) info connections
Num What Description
* 1 remote gdbserver - ~/tmp/hello.x Remote target using gdb-specific protocol
(gdb) python conn = gdb.selected_inferior().connection
(gdb) python print(conn.details)
gdbserver - ~/tmp/hello.x
(gdb)
I think there are two things wrong here, first in the "What" column of
the 'info connections' output, I think the text should be:
remote | gdbserver - ~/tmp/hello.x
to correctly show the user how the connection was established. And in
a similar fashion, I think that the `details` string of the
gdb.TargetConnection object should be:
| gdbserver - ~/tmp/hello.x
This commit makes this change. Currently the '|' is detected and
removed in gdb/serial.c. The string passed to the pipe_ops
structure (from gdb/ser-pipe.c), doesn't then, contain the `|`, this
is instead implied by the fact that it is a pipes based implementation
of the serial_ops interface.
After this commit we still detect the `|` in gdb/serial.c, but we now
store the full string (including the `|`) in the serial::name member
variable.
For pipe based serial connections, this name is only used for
displaying the two fields I mention above, and in pipe_open (from
gdb/ser-pipe.c), and in pipe_open, we now know to skip over the `|`.
The benefit I see from this change is that GDB's output now more
accurately reflects the commands used to start a target, thus making
it easier for a user to understand what is going on.
|
|
In the current code, if decimal floating point is not supported for
this target, there is no binary file dfp-test, and also there is no
test result after execute the following commands:
$ make check-gdb TESTS="gdb.base/dfp-test.exp"
$ grep error gdb/testsuite/gdb.log
/home/loongson/gdb.git/gdb/testsuite/gdb.base/dfp-test.c:39:1: error: decimal floating point not supported for this target
[...]
$ cat gdb/testsuite/gdb.sum
[...]
Running target unix
Running /home/loongson/gdb.git/gdb/testsuite/gdb.base/dfp-test.exp ...
=== gdb Summary ===
[...]
With this patch:
$ make check-gdb TESTS="gdb.base/dfp-test.exp"
$ cat gdb/testsuite/gdb.sum
[...]
Running target unix
Running /home/loongson/gdb.git/gdb/testsuite/gdb.base/dfp-test.exp ...
UNSUPPORTED: gdb.base/dfp-test.exp: decimal floating point not supported for this target.
=== gdb Summary ===
# of unsupported tests 1
[...]
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
Move the "started" variable to the scope it's needed, and rename it to
"step_over_started".
Change-Id: I56f3384dbd328f55198063bb855edda10f1492a3
|
|
This file is generated, so we should not modify it (any modification
we make is going to be undone at the next re-generation anyway).
|
|
Since commit ce2d3708bc8b ("Synchronize binutils libiberty sources with
gcc version."), I see this failure:
demangle _D8demangle4testFnZv^M
demangle.test(typeof(null))^M
(gdb) FAIL: gdb.dlang/demangle.exp: _D8demangle4testFnZv
The commit imported the commit 0e32a5aa8bc9 ("libiberty: Add support for
D `typeof(*null)' types") from the gcc repository. That commit includes
an update to libiberty/testsuite/d-demangle-expected, which updates a
test for the exact same mangled name:
_D8demangle4testFnZv
-demangle.test(none)
+demangle.test(typeof(null))
I don't know anything about D, but give that the change was made by Iain
Buclaw, the D language maintainer, I trust him on that.
Fix our test by updating the expected output in the same way.
Note: it's not really useful to have all these D demangling tests in the
GDB testsuite, since there are demangling tests in libiberty. We should
consider removing them, but we first need to make sure that everything
that is covered in gdb/testsuite/gdb.dlang/demangle.exp is also covered
in libiberty/testsuite/d-demangle-expected.
Change-Id: If2b290ea8367b8e1e0b90b20d4a6e0bee517952d
|
|
Intel Next Gen compiler defines preprocessor __INTEL_LLVM_COMPILER and provides
version info in __clang_version__ e.g. value: 12.0.0 (icx 2020.10.0.1113).
gdb/testsuite/ChangeLog:
2020-12-07 Abdul Basit Ijaz <abdul.b.ijaz@intel.com>
* lib/compiler.c: Add Intel next gen compiler pre-processor check.
* lib/compiler.cc: Ditto.
* lib/fortran.exp (fortran_main): Check Intel next gen compiler in
test_compiler_info.
|
|
This commit aims to not make use of -Wmissing-prototypes when
compiling with g++.
Use of -Wmissing-prototypes was added with this commit:
commit a0761e34f054767de6d6389929d27e9015fb299b
Date: Wed Mar 11 15:15:12 2020 -0400
gdb: enable -Wmissing-prototypes warning
Because clang can provide helpful warnings with this flag.
Unfortunately, g++ doesn't accept this flag, and will give this
warning:
cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++
In theory the fact that this flag is not supported should be detected
by the configure check in gdbsupport/warning.m4, but for users of
ccache, this check doesn't work due to a long standing ccache issue:
https://github.com/ccache/ccache/issues/738
The ccache problem is that -W... options are reordered on the command
line, and so -Wmissing-prototypes is seen before -Werror. Usually
this doesn't matter, but the above warning (about the flag not being
valid) is issued before the -Werror flag is processed, and so is not
fatal.
There have been two previous attempts to fix this that I'm aware of.
The first is:
https://sourceware.org/pipermail/gdb-patches/2021-September/182148.html
In this attempt, instead of just relying on a compile to check if a
flag is valid, the proposal was to both compile and link. As linking
doesn't go through ccache, we don't suffer from the argument
reordering problem, and the link phase will correctly fail when using
-Wmissing-prototypes with g++. The configure script will then disable
the use of this flag.
This approach was rejected, and the suggestion was to only add the
-Wmissing-prototypes flag if we are compiling with gcc.
The second attempt, attempts this approach, and can be found here:
https://sourceware.org/pipermail/gdb-patches/2021-November/183076.html
This attempt only adds the -Wmissing-prototypes flag is the value of
GCC is not 'yes'. This feels like it is doing the right thing,
unfortunately, the GCC flag is really a 'is gcc like' flag, not a
strict, is gcc check. As such, GCC is set to 'yes' for clang, which
would mean the flag was not included for clang or gcc. The entire
point of the original commit was to add this flag for clang, so
clearly the second attempt is not sufficient either.
In this new attempt I have added gdbsupport/compiler-type.m4, this
file defines AM_GDB_COMPILER_TYPE. This macro sets the variable
GDB_COMPILER_TYPE to either 'gcc', 'clang', or 'unknown'. In future
the list of values might be extended to cover other compilers, if this
is ever useful.
I've then modified gdbsupport/warning.m4 to only add the problematic
-Wmissing-prototypes flag if GDB_COMPILER_TYPE is not 'gcc'.
I've tested this with both gcc and clang and see the expected results,
gcc no longer attempts to use the -Wmissing-prototypes flag, while
clang continues to use it.
When compiling using ccache, I am no longer seeing the warning.
|
|
While working on another patch I wanted to add some extra debug
information to the attach_command function. This required me to add a
new function to convert the thread_info::state variable to a string.
The new debug might be useful to others, and the state to string
function might be useful in other locations, so I thought I'd merge
it.
|
|
This reverts the commit ff656e2e1cb1 ("gdb: testsuite: fix failed
testcases in gdb.base/charset.exp").
The original test code has no problem. On an architecture where
char is signed, then both 'A' and ebcdic_us_string[7] will yield
-63, which makes the equality true. On an architecture where char
is unsigned, then both 'A' and ebcdic_us_string[7] will yield 193,
which also makes the equality true.
The test cases only failed on LoongArch. The default type of char
is signed char on LoongArch, like x86-64. But when use gdb print
command on LoongArch, the default type of char is unsigned char,
this is wrong, I will look into it later, sorry for that.
On LoongArch:
$ cat test_char.c
#include <stdio.h>
int main()
{
char c1 = 193;
unsigned char c2 = 193;
printf("%d\n", c1);
printf("%d\n", c1 == c2);
return 0;
}
$ gcc test_char.c -o test_char
$ ./test_char
-63
0
(gdb) set target-charset EBCDIC-US
(gdb) print 'A'
$1 = 193 'A'
(gdb) print /c 'A'
$2 = 193 'A'
(gdb) print /u 'A'
$3 = 193
(gdb) print /d 'A'
$4 = -63
(gdb) print /x 'A'
$5 = 0xc1
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
The Power 9 processor revision 2.2 has HW watchpoint support disabled due
to a HW bug. The support is fixed in Power 9 processor revision 2.3. This
patch add a test to lib/gdb.exp for Power to determine if the processor
supports HW watchpoints or not. If the Power processor doesn't support HW
watchpoints the proceedure skip_hw_watchpoint_tests will return 1 to
disable the various HW watchpoint tests.
The patch has been tested on Power 9, processor revesions 2.2 and 2.3. The
patch has also been tested on Power 10. No regression test failures were
found.
|
|
We already have gdb.target_charset and gdb.target_wide_charset. This
commit adds gdb.host_charset along the same lines.
|
|
When executed with --target_board=native-extended-gdbserver, the
gdb.python/py-events.exp test errors out with
ERROR: tcl error sourcing /path/to/gdb/testsuite/gdb.python/py-events.exp.
ERROR: can't read "process_id": no such variable
while executing
"lappend expected "ptid: \\($process_id, $process_id, 0\\)" "address: $addr""
(file "/path/to/gdb/testsuite/gdb.python/py-events.exp" line 103)
invoked from within
"source /path/to/gdb/testsuite/gdb.python/py-events.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source /path/to/gdb/testsuite/gdb.python/py-events.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
There are multiple problems around this:
1. The process_id variable is not initialized to a default value.
2. The test attempts to find the PID of the current thread, but the
regexp that it uses is not tailored for the output printed by the
remote target.
3. The test uses "info threads" to find the current thread PID.
Using the "thread" command instead is simpler.
Fix these problems.
|
|
PR remote/9177 points out that "info files" mentions "serial" a couple
of times:
Remote serial target in gdb-specific protocol:
Debugging a target over a serial line.
However, often the remote target isn't really a serial connection.
It seems to me that this text could be a bit clearer; and furthermore
since "info files" prints the target's long description,
remote_target::files_info doesn't really add much and can simply be
removed.
Regression tested on x86-64 Fedora 34.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=9177
|
|
In a later commit I want to address an issue with the Python pygments
based code styling solution. As this approach is only used when the
GNU Source Highlight library is not available, testing bugs in this
area can be annoying, as it requires GDB to be rebuilt with use of GNU
Source Highlight disabled.
This commit adds a pair of new maintenance commands:
maintenance set gnu-source-highlight enabled on|off
maintenance show gnu-source-highlight enabled
these commands can be used to disable use of the GNU Source Highlight
library, allowing me, in a later commit, to easily test bugs that
would otherwise be masked by GNU Source Highlight being used.
I made this a maintenance command, rather than a general purpose
command, as it didn't seem like this was something a general user
would need to adjust. We can always convert the maintenance command
to a general command later if needed.
There's no test for this here, but this feature will be used in a
later commit.
|
|
The source_cache class has two member variables m_source_map, which
stores the file contents, and m_offset_cache, which stores offsets
into the file contents.
As source files are read the contents of the file, as well as the
offset data, are stored in the cache using these two member variables.
Whenever GDB needs either the files contents, or the offset data,
source_cache::ensure is called. This function looks for the file in
m_source_map, and if it's found then this implies the file is also in
m_offset_cache, and we're done.
If the file is not in m_source_map then GDB calls
source_cache::get_plain_source_lines to open the file and read its
contents. ::get_plain_source_lines also calculates the offset data,
which is then inserted into m_offset_cache.
Back in ::ensure, the file contents are added into m_source_map. And
finally, if m_source_map contains more than MAX_ENTRIES, an entry is
removed from m_source_map.
The problem is entries are not removed from m_offset_cache at the same
time.
This means that if a program contains enough source files, GDB will
hold at most MAX_ENTRIES cached source file contents, but can contain
offsets data for every source file.
Now, the offsets data is going to be smaller than the cached file
contents, so maybe there's no harm here. But, when we reload the file
contents we always recalculate the offsets data. And, when we
::get_line_charpos asking for offset data we still call ::ensure which
will ends up loading and caching the file contents.
So, given the current code does the work of reloading the offset data
anyway, we may as well save memory by capping m_offset_cache to
MAX_ENTRIES just like we do m_source_map.
That's what this commit does.
There should be no user visible changes after this commit, except for
ever so slightly lower memory usage in some cases.
|
|
This commit adds a new 'maint flush source-cache' command, this
flushes the cache of source file contents.
After flushing GDB is forced to reread source files the next time any
source lines are to be displayed.
I've added a test for this new feature. The test is a little weird,
in that it modifies a source file after compilation, and makes use of
the cache flush so that the changes show up when listing the source
file. I'm not sure when such a situation would ever crop up in real
life, but maybe we can imagine such cases.
In reality, this command is useful for testing the syntax highlighting
within GDB, we can adjust the syntax highlighting settings, flush the
cache, and then get the file contents re-highlighted using the new
settings.
|
|
Rename 'set debug lin-lwp' to 'set debug linux-nat' and 'show debug
lin-lwp' to 'show debug linux-nat'.
I've updated the documentation and help text to match, as well as
making it clear that the debug that is coming out relates to all
aspects of Linux native inferior support, not just the LWP aspect of
it.
The boundary between general "native" target debug, and the lwp
specific part of that debug was always a little blurry, but the actual
debug variable inside GDB is debug_linux_nat, and the print routine
linux_nat_debug_printf, is used throughout the linux-nat.c file, not
just for lwp related debug, so the new name seems to make more sense.
|
|
In gdb/testsuite/gdb.base/charset.c, use "IBM1047" instead of "EBCDIC"
to fix the wrong comment.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
In gdb/testsuite/gdb.base/charset.c, the last argument is greater than 127
when call fill_run() in EBCDIC-US and IBM1047, but the type of string[] is
char, this will change the value due to sign extension.
For example, ebcdic_us_string[7] will be -63 instead of the original 193 in
EBCDIC-US.
Make the type of string[] as unsigned char to fix the following six failed
testcases:
$ grep FAIL gdb/testsuite/gdb.sum
FAIL: gdb.base/charset.exp: check value of parsed character literal in EBCDIC-US
FAIL: gdb.base/charset.exp: check value of parsed string literal in EBCDIC-US
FAIL: gdb.base/charset.exp: check value of escape that doesn't exist in EBCDIC-US
FAIL: gdb.base/charset.exp: check value of parsed character literal in IBM1047
FAIL: gdb.base/charset.exp: check value of parsed string literal in IBM1047
FAIL: gdb.base/charset.exp: check value of escape that doesn't exist in IBM1047
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
The Darwin code uses unfiltered output liberally. This patch changes
this code to send some output to gdb_stdlog (in some cases via the use
of debug_prefixed_printf_cond_nofunc), or to gdb_stderr, or to simply
switch to filtered output.
Note that I didn't switch inferior_debug to use
debug_prefixed_printf_cond_nofunc, because that would affect the
output by removing the information about the inferior. I wasn't sure
if this was important or not, so I left it in.
v2 of this patch uses warning rather than prints to gdb_stderr, and
removes some trailing whitespace.
I can't compile this patch, so it's "best effort".
|
|
While testing on GNU/Hurd (i386) I noticed that GDB crashes when an
inferior exits, with this error:
inferior.c:293: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed.
The problem appears to be in gnu_nat_target::wait.
We always set inferior_ptid to null_ptid before calling target_wait,
this has been the case since the multi-target changes were made to GDB
in commit:
commit 5b6d1e4fa4fc6827c7b3f0e99ff120dfa14d65d2
Date: Fri Jan 10 20:06:08 2020 +0000
Multi-target support
With follow up changes in commit:
commit 24ed6739b699f329c2c45aedee5f8c7d2f54e493
Date: Thu Jan 30 14:35:40 2020 +0000
gdb/remote: Restore support for 'S' stop reply packet
Unfortunately, the GNU/Hurd target is still relying on the value of
inferior_ptid in the case where an inferior exits - we return the
value of inferior_ptid as the pid of the process that exited. This
was fine in the single target world, where inferior_ptid identified
the one running inferior, but this is no longer good enough.
Instead, we should return a ptid containing the pid of the process
that exited, as obtained from the wait event, and this is what this
commit does.
I've not run the full testsuite on GNU/Hurd as there appear to be lots
of other issues with this target that makes running the full testsuite
very painful, but I think this looks like a small easy improvement.
|
|
Lancelot pointed out that target_announce_attach was missing an
explicit check against nullptr. This patch adds it.
|
|
This patch adds information about _sigsys structure from newer
kernels, so that $_siginfo decoding can show information about
_sigsys, making it easier for developers to debug seccomp failures.
Requested in PR gdb/24283.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24283
|
|
Add "show print array-indexes" testcases after set print array-indexes
to off or on.
Without this patch:
PASS: gdb.base/arrayidx.exp: set print array-indexes to off
PASS: gdb.base/arrayidx.exp: print array with array-indexes off
PASS: gdb.base/arrayidx.exp: set print array-indexes to on
PASS: gdb.base/arrayidx.exp: print array with array-indexes on
With this patch:
PASS: gdb.base/arrayidx.exp: set print array-indexes to off
PASS: gdb.base/arrayidx.exp: show print array-indexes is off
PASS: gdb.base/arrayidx.exp: print array with array-indexes off
PASS: gdb.base/arrayidx.exp: set print array-indexes to on
PASS: gdb.base/arrayidx.exp: show print array-indexes is on
PASS: gdb.base/arrayidx.exp: print array with array-indexes on
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
When I run the testsuite, I have:
Running .../gdb/testsuite/gdb.mi/mi-catch-load.exp ...
DUPLICATE: gdb.mi/mi-catch-load.exp: breakpoint at main
DUPLICATE: gdb.mi/mi-catch-load.exp: mi runto main
Fix by grouping the various phases in with_test_prefix blocks. Since
the tests now have a prefix, remove the manually written prefixes in
testnames.
Also change some messages with the pattern "(timeout) $testname" into
"$estname (timeout)" since tools will handle this as $testname[1] (which
is what we want in this particular scenario).
Tested on x86_64-linux.
[1] https://sourceware.org/gdb/wiki/GDBTestcaseCookbook#Do_not_use_.22tail_parentheses.22_on_test_messages
|
