| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This patch finally enables the new indexer. It is left until this
point in the series to avoid any regressions; in particular, it has to
come after the changes to the DWARF index writer to avoid this
problem.
However, if you experiment with the series, this patch can be moved
anywhere from the patch to wire in the new reader to this point.
Moving this patch around is how I got separate numbers for the
parallelization and background finalization patches.
In the ongoing performance example, this reduces the time from the
baseline of 1.598869 to 0.903534.
|
|
This commit ports these two fixes to the C parser:
commit ebf13736b42af47c9907b5157c8e80c78dbe00e1
CommitDate: Thu Sep 4 21:46:28 2014 +0100
parse_number("0") reads uninitialized memory
commit 20562150d8a894bc91657c843ee88c508188e32e
CommitDate: Wed Oct 3 15:19:06 2018 -0600
Avoid undefined behavior in parse_number
... to the Fortran, Go, and Fortran number parsers, fixing the same
problems there.
Also add a new testcase that exercises printing 0xffffffffffffffff
(max 64-bit) in all languages, which crashes a GDB built with UBsan
without the fix.
I moved get_set_option_choices out of all-architectures.exp.tcl to
common code to be able to extract all the supported languages. I did
a tweak to it to generalize it a bit -- you now have to pass down the
"set" part of the command as well. This is so that the proc can be
used with "maintenance set" commands as well in future.
Change-Id: I8e8f2fdc1e8407f63d923c26fd55d98148b9e16a
|
|
Make gdb_compile handle a new "macros" option, which makes it pass the
appropriate flag to make the compiler include macro information in the
debug info. This will help simplify tests using macros, reduce
redundant code, and make it easier to add support for a new compiler.
Right now it only handles clang specially (using -fdebug-macro) and
falls back to -g3 otherwise (which works for gcc). Other compilers can
be added as needed.
There are some tests that are currently skipped if the compiler is nor
gcc nor clang. After this patch, the tests will attempt to run (the -g3
fall back will be used). That gives a chance to people using other
compilers to notice something is wrong and maybe add support for their
compiler. If it is needed to support a compiler that doesn't have a way
to include macro information, then we can always introduce a
"skip_macro_tests" that can be used to skip over them.
Change-Id: I50cd6ab1bfbb478c1005486408e214b551364c9b
|
|
By calling `uplevel $body` in the program proc (a pattern we use at many
places), we can get rid of curly braces around each line number program
directive. That seems like a nice small improvement to me.
Change-Id: Ib327edcbffbd4c23a08614adee56c12ea25ebc0b
|
|
These variables seem to be unused, remove them.
Change-Id: I7d613d9d35735930ee78b2c348943c73a702afbb
|
|
Change gdb_breakpoint to accept a linespec, not just a function. In
fact, no behavior changes are necessary, this only changes the parameter
name and documentation. Change runto as well, since the two are so
close (runto forwards all its arguments to gdb_breakpoint).
I wrote this for a downstrean GDB port, but thought it could be
useful upstream, eventually, even though not callers take advantage of
it yet.
Change-Id: I08175fd444d5a60df90fd9985e1b5dfd87c027cc
|
|
Add support for DW_LNS_set_prologue_end when building line-tables. This
attribute can be set by the compiler to indicate that an instruction is
an adequate place to set a breakpoint just after the prologue of a
function.
The compiler might set multiple prologue_end, but considering how
current skip_prologue_using_sal works, this commit modifies it to accept
the first instruction with this marker (if any) to be the place where a
breakpoint should be placed to be at the end of the prologue.
The need for this support came from a problematic usecase generated by
hipcc (i.e. clang). The problem is as follows: There's a function
(lets call it foo) which covers PC from 0xa800 to 0xa950. The body of
foo begins with a call to an inlined function, covering from 0xa800 to
0xa94c. The issue is that when placing a breakpoint at 'foo', GDB
inserts the breakpoint at 0xa818. The 0x18 offset is what GDB thinks is
foo's first address past the prologue.
Later, when hitting the breakpoint, GDB reports the stop within the
inlined function because the PC falls in its range while the user
expects to stop in FOO.
Looking at the line-table for this location, we have:
INDEX LINE ADDRESS IS-STMT
[...]
14 293 0x000000000000a66c Y
15 END 0x000000000000a6e0 Y
16 287 0x000000000000a800 Y
17 END 0x000000000000a818 Y
18 287 0x000000000000a824 Y
[...]
For comparison, let's look at llvm-dwarfdump's output for this CU:
Address Line Column File ISA Discriminator Flags
------------------ ------ ------ ------ --- ------------- -------------
[...]
0x000000000000a66c 293 12 2 0 0 is_stmt
0x000000000000a6e0 96 43 82 0 0 is_stmt
0x000000000000a6f8 102 18 82 0 0 is_stmt
0x000000000000a70c 102 24 82 0 0
0x000000000000a710 102 18 82 0 0
0x000000000000a72c 101 16 82 0 0 is_stmt
0x000000000000a73c 2915 50 83 0 0 is_stmt
0x000000000000a74c 110 1 1 0 0 is_stmt
0x000000000000a750 110 1 1 0 0 is_stmt end_sequence
0x000000000000a800 107 0 1 0 0 is_stmt
0x000000000000a800 287 12 2 0 0 is_stmt prologue_end
0x000000000000a818 114 59 81 0 0 is_stmt
0x000000000000a824 287 12 2 0 0 is_stmt
0x000000000000a828 100 58 82 0 0 is_stmt
[...]
The main difference we are interested in here is that llvm-dwarfdump's
output tells us that 0xa800 is an adequate place to place a breakpoint
past a function prologue. Since we know that foo covers from 0xa800 to
0xa94c, 0xa800 is the address at which the breakpoint should be placed
if the user wants to break in foo.
This commit proposes to add support for the prologue_end flag in the
line-program processing.
The processing of this prologue_end flag is made in skip_prologue_sal,
before it calls gdbarch_skip_prologue_noexcept. The intent is that if
the compiler gave information on where the prologue ends, we should use
this information and not try to rely on architecture dependent logic to
guess it.
The testsuite have been executed using this patch on GNU/Linux x86_64.
Testcases have been compiled with both gcc/g++ (verison 9.4.0) and
clang/clang++ (version 10.0.0) since at the time of writing GCC does not
set the prologue_end marker. Tests done with GCC 11.2.0 (not over the
entire testsuite) show that it does not emit this flag either.
No regression have been observed with GCC or Clang. Note that when
using Clang, this patch fixes a failure in
gdb.opt/inline-small-func.exp.
Change-Id: I720449a8a9b2e1fb45b54c6095d3b1e9da9152f8
|
|
This patch was original part of this series:
https://sourceware.org/pipermail/gdb-patches/2022-March/186429.html
https://sourceware.org/pipermail/gdb-patches/2022-March/186433.html
I've pulled this out as it might be useful ahead of the bigger series
being merged.
This commit adds:
_csi_L - insert line
_csi_S - pan down
_csi_T - pan up
|
|
Since commit 3cd522938792 ("Change the pager to a ui_file"), I see these
errors when running gdb.tui/scroll.exp:
ERROR: invalid command name "_csi_P"
while executing
"::gdb_tcl_unknown _csi_P 2"
("uplevel" body line 1)
invoked from within
"uplevel 1 ::gdb_tcl_unknown $args"
(procedure "::unknown" line 5)
invoked from within
"_csi_P 2"
("eval" body line 1)
invoked from within
"eval _csi_$cmd $params"
It looks like GDB is emitting a CSI that it did not emit before, the
"Delete character" one:
https://vt100.net/docs/vt510-rm/DCH.html
Implement it.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I5bf86b6104d51b0623a26a69df83d1ca9a4851b7
|
|
While trying to review Andrew's patch here [1], I thought I spotted a
bug in the handling of a CSI, but I had no way to know for sure. So I
thought it would be useful to have unit tests for the handling of
control characters and control sequences of our toy terminal
implementation. It might help avoid chasing bugs in the GDB TUI when in
reality it's a problem with the testsuite's terminal implementation.
Add the gdb.tui/tuiterm.exp file to do that. All currently supported
control sequences and characters are tested, except _csi_m (the one that
handles colors and stuff). _csi_m should probably be tested too, but it
will require more work.
Fix a few issues that the tests spotted:
- backspace: according to [3] (table 4-1), a backspace when the cursor
is at the beginning of a line should have no effect. Our
implementation did wrap to the end of the previous line. Change our
implementation to match the doc (and the test).
- insert character: this control sequence is supposed to insert blank
characters, shifting all the rest of the line right. The current
implementation moves N characters right, but it overwrites the
characters on the right instead of shifting them. It also doesn't
insert blank characters at the cursor.
- Cursor down, forward, next line: off-by-one error when reaching the
end of the display.
- erase in display, line: off-by-one errors.
- vertical line position absolute: allowed setting the cursor outside
the display, when it should clamp it to the display size.
I found that this web page [2] gave some good clues on the expected
behavior of some control characters or sequences that some other pages
didn't.
[1] https://sourceware.org/pipermail/gdb-patches/2022-March/186433.html
[2] https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences
[3] https://vt100.net/docs/vt510-rm/chapter4.html#S4.3.3
Change-Id: Iab4141fdcfb7459d1b7c45cc63bd1fcb50a78d5d
|
|
New in this version:
- Add a PY_MAJOR_VERSION check in configure.ac / AC_TRY_LIBPYTHON. If
the user passes --with-python=python2, this will cause a configure
failure saying that GDB only supports Python 3.
Support for Python 2 is a maintenance burden for any patches touching
Python support. Among others, the differences between Python 2 and 3
string and integer types are subtle. It requires a lot of effort and
thinking to get something that behaves correctly on both. And that's if
the author and reviewer of the patch even remember to test with Python
2.
See this thread for an example:
https://sourceware.org/pipermail/gdb-patches/2021-December/184260.html
So, remove Python 2 support. Update the documentation to state that GDB
can be built against Python 3 (as opposed to Python 2 or 3).
Update all the spots that use:
- sys.version_info
- IS_PY3K
- PY_MAJOR_VERSION
- gdb_py_is_py3k
... to only keep the Python 3 portions and drop the use of some
now-removed compatibility macros.
I did not update the configure script more than just removing the
explicit references to Python 2. We could maybe do more there, like
check the Python version and reject it if that version is not
supported. Otherwise (with this patch), things will only fail at
compile time, so it won't really be clear to the user that they are
trying to use an unsupported Python version. But I'm a bit lost in the
configure code that checks for Python, so I kept that for later.
Change-Id: I75b0f79c148afbe3c07ac664cfa9cade052c0c62
|
|
This commit adds new gdb_attach to centralize the failure checking of
"attach" command. Return 0 if attach failed, otherwise return 1.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
As Pedro Alves said, caching procs should not issue pass/fail [1],
this commit removes attach test from can_spawn_for_attach, at the
same time, use "verbose -log" instead of "unsupported" to get a
trace about why a test run doesn't support spawning for attach.
[1] https://sourceware.org/pipermail/gdb-patches/2022-March/186311.html
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
In testsuite/README, we suggest that you can run the testsuite against
some other GDB binary by using:
make check RUNTESTFLAGS=GDB=/usr/bin/gdb
However, that example isn't fully correct, because with that command
line, the testsuite will still pass
-data-directory=[pwd]/../data-directory
to /usr/bin/gdb, like e.g.:
...
builtin_spawn /usr/bin/gdb -nw -nx -data-directory /home/pedro/gdb/build/gdb/testsuite/../data-directory -iex set height 0 -iex set width 0
...
while if you're testing an installed GDB (the system GDB being the
most usual scenario), then you should normally let it use its own
configured directory, not the just-built GDB's data directory.
This commit improves the status quo with the following two changes:
- if the user specifies GDB on the command line, then by default,
don't start GDB with the -data-directory command line option.
I.e., let the tested GDB use its own configured data directory.
- let the user override the data directory, via a new
GDB_DATA_DIRECTORY global. This replaces the existing
BUILD_DATA_DIRECTORY variable in testsuite/lib/gdb.exp, which
wasn't overridable, and was a bit misnamed for the new purpose.
So after this, the following commands I believe behave intuitively:
# Test the non-installed GDB in some build dir:
make check \
RUNTESTFLAGS="GDB=/path/to/other/build/gdb \
GDB_DATA_DIRECTORY=/path/to/other/build/gdb/data-directory"
# Test the GDB installed in some prefix:
make check \
RUNTESTFLAGS="GDB=/opt/gdb/bin/gdb"
# Test the built GDB with some alternative data directory, e.g., the
system GDB's data directory:
make check \
RUNTESTFLAGS="GDB_DATA_DIRECTORY=/usr/share/gdb"
Change-Id: Icdc21c85219155d9564a9900961997e6624b78fb
|
|
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
|
|
When execute the following command:
make check-gdb TESTS="gdb.base/gdb-caching-proc.exp"
we can see there exist some failed testcases:
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 0: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 1: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 2: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 3: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 4: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 5: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 6: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 7: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 8: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 9: can spawn for attach (got interactive prompt)
here are the detailed messages in gdb/testsuite/gdb.log:
attach 873776
A program is being debugged already. Kill it? (y or n) n
Not killed.
(gdb) FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 0: can spawn for attach (got interactive prompt)
so handle the case "A program is being debugged already. Kill it" in
can_spawn_for_attach to fix the failed testcases.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
If /proc/sys/kernel/yama/ptrace_scope is 1, when execute the test case
gdb.base/attach-pie-noexec.exp without superuser, the gdb.log shows the
following info:
(gdb) attach 6500
Attaching to process 6500
ptrace: Operation not permitted.
(gdb) PASS: gdb.base/attach-pie-noexec.exp: attach
It is obviously wrong, the expected result should be UNSUPPORTED in such
a case.
It is better to make can_spawn_for_attach to return false for this case.
It would have to setup a small test program, compile it to exec, spawn it
and try to attach to it.
With this patch, we can see "Operation not permitted" in the log info,
and then we can do the following processes to test:
(1) set ptrace_scope as 0
$ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
$ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
(2) use sudo
$ sudo make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
Additionally, handle the other cases when test with RUNTESTFLAGS=
"--target_board=native-extended-gdbserver".
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
In the current code, there is no test result when execute the following
commands:
$ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp" RUNTESTFLAGS="--target_board=remote-gdbserver-on-localhost"
$ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
It is better to print explicit test result in can_spawn_for_attach.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
This is a snafu that I encountered while implementing the previous
patch, which attempted to use gdb_is_target_native. This proc and
gdb_is_target_remote both rely on gdb_is_target_1, which actually
cannot be called without gdb already running.
This patch adds appropriate warning comments to these procs and
causes gdb_is_target_1 to issue a Tcl error if it is called without a
gdb instance already running. This should prevent unwitting callers
from using this at the wrong time.
|
|
I came across this problem when testing gdb.base/gdb-sigterm.exp
on a machine with a pre-release version of glib-2.34 installed:
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) Recursive internal problem.
FAIL: gdb.base/gdb-sigterm.exp: expect eof #0 (GDB internal error)
Resyncing due to internal error.
ERROR: : spawn id exp11 not open
while executing
"expect {
-i exp11 -timeout 10
-re "Quit this debugging session\\? \\(y or n\\) $" {
send_gdb "n\n" answer
incr count
}
-re "Create..."
("uplevel" body line 1)
invoked from within
"uplevel $body" NONE : spawn id exp11 not open
ERROR: Could not resync from internal error (timeout)
gdb.base/gdb-sigterm.exp: expect eof #0: stepped 9 times
UNRESOLVED: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes
I don't have a problem with the latter ERROR nor the UNRESOLVED
messages. However the first ERROR regarding the exp11 spawn id
not being open is not especially useful.
This commit handles the "Recursive internal problem" case, avoiding
the problematic ERROR shown above.
With this commit in place, the log messages look like this instead:
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) Recursive internal problem.
FAIL: gdb.base/gdb-sigterm.exp: expect eof #15 (GDB internal error)
Resyncing due to internal error.
ERROR: Could not resync from internal error (recursive internal problem)
gdb.base/gdb-sigterm.exp: expect eof #15: stepped 12 times
UNRESOLVED: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_internal_error_resync): Handle "Recursive
internal problem".
|
|
The INTERNAL_GDBFLAGS runtest variable was updated in 55c3ad88013
([gdb/testsuite] Prevent pagination in GDB_INTERNALFLAGS, 2020-10-26) to
disable pagination, and in aae1c79a03a (PR python/12227..., 2010-12-07)
to point to the data directory, but its default value mentioned in the
testsuite's README was not kept up to date.
To avoid it getting out of sync even more, point the reader to the
definition of the variable in lib/gdb.exp, and move the explanation of
the different flags there. Also adjust the example in the README
so it follows the flags added in 55c3ad88013.
Change-Id: I3533608a7d6ae5198af09c7dc7743bde24c19ed7
|
|
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.
|
|
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.
|
|
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
|
|
There is a expect support library in the source tree designed to help
developers test the auto-completion capabilities of GDB.
One of the functions is test_gdb_complete_unique_re. It is used
(usually indirectly via test_gdb_complete_unique) to test that a given
input line is completed as a given output line. The test checks for two
ways to do the completion: using tab-completion, or using the
'complete' command. To do this, calls to two dedicated functions are
performed. If we omit few details, we can consider that a call to
test_gdb_complete_unique $input $expected
is equivalent to the two following calls:
test_gdb_complete_tab_unique $input $expected
test_gdb_complete_cmd_unique $input $expected
When using the tab-completion, everything works as expected, but some
care must be taken when using the 'complete' command if the given input
has leading whitespaces. In such situation, the output of the
'complete' command will drop the leading whitespaces.
The current approach is that in such situation, the input and expected
outputs are right trimmed (i.e. all leading whitespaces are removed)
when performing the command completion check.
This means that the following call:
test_gdb_complete_unique " $input" " $expected"
is almost equivalent to (again, omitting few details and arguments):
test_gdb_complete_tab_unique " $input" " $expected"
test_gdb_complete_cmd_unique "$input" "$expected"
This approach comes with a problem that we encounter when running the
tests in complete-empty.exp. When doing so, we have:
Running .../gdb/testsuite/gdb.base/complete-empty.exp ...
DUPLICATE: gdb.base/complete-empty.exp: empty-input-line: cmd complete ""
This is because the test file does something like:
test_gdb_complete_unique "" "!" " " 1
test_gdb_complete_unique " " " !" " " 1¬
which, if we do the substitution introduced above is equivalent to:
test_gdb_complete_tab_unique "" "!"
test_gdb_complete_cmd_unique "" "!"
test_gdb_complete_tab_unique " " " !"
test_gdb_complete_cmd_unique "" "!"
We see that the lines 2 and 4 are now the same, and for this reason the
testing framework complains about DUPLICATE test names.
To fix that, this commit proposes that instead of left trimming both
input and expected outputs, only the expected output is trimmed.
Care must be taken in the case the completion gives more possibilities
than allowed by the max-completions setting. In this case, the input
will be repeated in the output in its left trimmed version. This commit
also ensures that this is taken care of.
With this commit, the gdb.base/complete-empty.exp still passes all its
tests but does not report the DUPLICATE anymore.
Tested on x86_64-linux.
|
|
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
|
|
PR26056 reports that when GDB is connected to non-TTY stdin/stdout, it
crashes when it receives a SIGWINCH signal.
This can be reproduced as follows:
$ gdb/gdb -nx -batch -ex 'run' --args sleep 60 </dev/null 2>&1 | cat
# from another terminal:
$ kill -WINCH %(pidof gdb)
When doing so, the process crashes in a call to rl_resize_terminal:
void
rl_resize_terminal (void)
{
_rl_get_screen_size (fileno (rl_instream), 1);
...
}
The problem is that at this point rl_instream has the value NULL.
The rl_instream variable is supposed to be initialized during a call to
readline_initialize_everything, which in a normal startup sequence is
called under this call chain:
tui_interp::init
tui_ensure_readline_initialized
rl_initialize
readline_initialize_everything
In tui_interp::init, we have the following sequence:
tui_initialize_io ();
tui_initialize_win (); // <- Installs SIGWINCH
if (gdb_stdout->isatty ())
tui_ensure_readline_initialized (); // <- Initializes rl_instream
This function unconditionally installs the SIGWINCH signal handler (this
is done by tui_initialize_win), and then if gdb_stdout is a TTY it
initializes readline. Therefore, if stdout is not a TTY, SIGWINCH is
installed but readline is not initialized. In such situation
rl_instream stays NULL, and when GDB receives a SIGWINCH it calls its
handler and in fine tries to access rl_instream leading to the crash.
This patch proposes to fix this issue by installing the SIGWINCH signal
handler only if GDB is connected to a TTY. Given that this
initialization it the only task of tui_initialize_win, this patch moves
tui_initialize_win just after the call to
tui_ensure_readline_initialized.
Tested on x86_64-linux.
Co-authored-by: Pedro Alves <pedro@palves.net>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26056
Change-Id: I6458acef7b0d9beda2a10715d0345f02361076d9
|
|
The documented behavior of proc runto is to not emit a PASS when
succeeding to to run to the specified location, but emit a FAIL when
failing to do so. I suppose the intent is that it won't pollute the
results normally passing tests (although I don't see why we would care),
but make visible any problems.
However, it seems like the implementation makes it default to never
print anything. "no-message" is prependend to "args", so if "message"
is not passed, we will always take the path that sets print_fail to 0,
which will silence any failure.
This unfortunately means that tests relying on runto_main won't emit a
FAIL if failing to run to main. And since commit 4dfef5be6812
("gdb/testsuite: make runto_main not pass no-message to runto"), tests
don't emit a FAIL themselves when failing to run to main. This means
that tests failing to run to main just fail silently, and that's bad.
This can be reproduced by hacking gdb.base/template.exp like so:
diff --git a/gdb/testsuite/gdb.base/template.c b/gdb/testsuite/gdb.base/template.c
index bcf39c377d92..052be5b79d73 100644
--- a/gdb/testsuite/gdb.base/template.c
+++ b/gdb/testsuite/gdb.base/template.c
@@ -15,6 +15,14 @@
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. */
+#include <stdlib.h>
+
+__attribute__((constructor))
+static void c (void)
+{
+ exit (1);
+}
+
int
main (void)
{
Running the modified gdb.base/template.exp shows that it exits without
printing any result.
Remove the line that prepends no-message to args, that should make
runto's behavior match its documentation.
This patch will appear to add many failures, but in reality they already
existed, they were just silenced.
Change-Id: I2a730d5bc72b6ef0698cd6aad962d9902aa7c3d6
|
|
While working with pending fork events, I wondered what would happen if
the user detached an inferior while a thread of that inferior had a
pending fork event. What happens with the fork child, which is
ptrace-attached by the GDB process (or by GDBserver), but not known to
the core? Sure enough, neither the core of GDB or the target detach the
child process, so GDB (or GDBserver) just stays ptrace-attached to the
process. The result is that the fork child process is stuck, while you
would expect it to be detached and run.
Make GDBserver detach of fork children it knows about. That is done in
the generic handle_detach function. Since a process_info already exists
for the child, we can simply call detach_inferior on it.
GDB-side, make the linux-nat and remote targets detach of fork children
known because of pending fork events. These pending fork events can be
stored in:
- thread_info::pending_waitstatus, if the core has consumed the event
but then saved it for later (for example, because it got the event
while stopping all threads, to present an all-stop stop on top of a
non-stop target)
- thread_info::pending_follow: if we ran to a "catch fork" and we
detach at that moment
Additionally, pending fork events can be in target-specific fields:
- For linux-nat, they can be in lwp_info::status and
lwp_info::waitstatus.
- For the remote target, they could be stored as pending stop replies,
saved in `remote_state::notif_state::pending_event`, if not
acknowledged yet, or in `remote_state::stop_reply_queue`, if
acknowledged. I followed the model of remove_new_fork_children for
this: call remote_notif_get_pending_events to process /
acknowledge any unacknowledged notification, then look through
stop_reply_queue.
Update the gdb.threads/pending-fork-event.exp test (and rename it to
gdb.threads/pending-fork-event-detach.exp) to try to detach the process
while it is stopped with a pending fork event. In order to verify that
the fork child process is correctly detached and resumes execution
outside of GDB's control, make that process create a file in the test
output directory, and make the test wait $timeout seconds for that file
to appear (it happens instantly if everything goes well).
This test catches a bug in linux-nat.c, also reported as PR 28512
("waitstatus.h:300: internal-error: gdb_signal target_waitstatus::sig()
const: Assertion `m_kind == TARGET_WAITKIND_STOPPED || m_kind ==
TARGET_WAITKIND_SIGNALLED' failed.). When detaching a thread with a
pending event, get_detach_signal unconditionally fetches the signal
stored in the waitstatus (`tp->pending_waitstatus ().sig ()`). However,
that is only valid if the pending event is of type
TARGET_WAITKIND_STOPPED, and this is now enforced using assertions (iit
would also be valid for TARGET_WAITKIND_SIGNALLED, but that would mean
the thread does not exist anymore, so we wouldn't be detaching it). Add
a condition in get_detach_signal to access the signal number only if the
wait status is of kind TARGET_WAITKIND_STOPPED, and use GDB_SIGNAL_0
instead (since the thread was not stopped with a signal to begin with).
Add another test, gdb.threads/pending-fork-event-ns.exp, specifically to
verify that we consider events in pending stop replies in the remote
target. This test has many threads constantly forking, and we detach
from the program while the program is executing. That gives us some
chance that we detach while a fork stop reply is stored in the remote
target. To verify that we correctly detach all fork children, we ask
the parent to exit by sending it a SIGUSR1 signal and have it write a
file to the filesystem before exiting. Because the parent's main thread
joins the forking threads, and the forking threads wait for their fork
children to exit, if some fork child is not detach by GDB, the parent
will not write the file, and the test will time out. If I remove the
new remote_detach_pid calls in remote.c, the test fails eventually if I
run it in a loop.
There is a known limitation: we don't remove breakpoints from the
children before detaching it. So the children, could hit a trap
instruction after being detached and crash. I know this is wrong, and
it should be fixed, but I would like to handle that later. The current
patch doesn't fix everything, but it's a step in the right direction.
Change-Id: I6d811a56f520e3cb92d5ea563ad38976f92e93dd
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28512
|
|
In commit 80ad340c902 ("[gdb/testsuite] use -Ttext-segment for jit-elf tests")
the following change was made:
...
proc compile_jit_elf_main_as_so {main_solib_srcfile main_solib_binfile options} {
- set options [concat $options debug]
+ global jit_load_address jit_load_increment
+
+ set options [list \
+ additional_flags="-DMAIN=jit_dl_main" \
+ additional_flags=-DLOAD_ADDRESS=$jit_load_address \
+ additional_flags=-DLOAD_INCREMENT=$jit_load_increment \
+ debug]
...
Before the change, the options argument was used, but after the change not
anymore.
Fix this by reverting back to using "set options [concat $options ...]".
Fixing this gets us twice the -DMAIN=jit_dl_main bit, once from a caller, and
once from compile_jit_elf_main_as_so. Fix this by removing the bit from
compile_jit_elf_main_as_so, which makes the code similar to compile_jit_main.
Tested on x86_64-linux.
|
|
Test-cases gdb.arch/i386-{avx,sse}.exp use assembly instructions that require
the memory operands to be aligned to a certain boundary, and the test-cases
use C11's _Alignas to make that happen.
The draw-back of using _Alignas is that while it does enforce a minimum
alignment, the actual alignment may be bigger, which makes the following
scenario possible:
- copy say, gdb.arch/i386-avx.c as basis for a new test-case
- run the test-case and observe a PASS
- commit the new test-case in the supposition that the test-case is correct
and well-tested
- run later into a failure on a different test setup (which may be a setup
where reproduction and investigation is more difficult and time-consuming),
and find out that the specified alignment was incorrect and should have been
updated to say, 64 bytes. The initial PASS occurred only because the actual
alignment happened to be greater than required.
The idea of having precise alignment as a means of having more predictable
execution which allows flushing out bugs earlier, has been filed as PR
gcc/103095.
Add a new file lib/precise-aligned-alloc.c with functions
precise_aligned_alloc and precise_aligned_dup, to support precise alignment.
Use precise_aligned_dup in aforementioned test-cases to:
- verify that the specified alignment is indeed sufficient, rather
than too little but accidentally over-aligned.
- prevent the same type of problems in any new test-cases based on these
Tested on x86_64-linux, with both gcc and clang.
|
|
Commit ab557072b8ec ("gdb: use actual DWARF version in compunit's
debugformat field") changes the debug format string in "info source" to
show the actual DWARF version, rather than always show "DWARF 2".
However, it failed to consider that some tests checked for the "DWARF 2"
string to see if the test program is compiled with DWARF debug
information. Since everything is compiled with DWARF 4 or 5 nowadays,
that changed the behavior of those tests. Notably, it prevent the
tests using skip_inline_var_tests to run.
Grep through the testsuite for "DWARF 2" and change all occurrences I
could find to use "DWARF [0-9]" instead (that string is passed to TCL's
string match).
Change-Id: Ic7fb0217fb9623880c6f155da6becba0f567a885
|
|
The gdb.python/py-inferior-leak.exp test makes use of the tracemalloc
module. When running the Python tests with a GDB built against Python
2 I ran into a test failure due to the tracemalloc module not being
available.
This commit adds a new helper function to lib/gdb-python.exp that
checks if a named module is available. Using this we can then skip
the py-inferior-leak.exp test when the tracemalloc module is not
available.
|
|
Proc lines contains a typo:
...
string_form { set $_line_string_form $value }
...
Remove the incorrect '$' in '$_line_string_form'.
Tested on x86_64-linux.
|
|
While debugging a problem in gdb.dwarf2/dw2-lines.exp, I realized that the
test-case generates all executables and associated temporary files using the
same filenames.
Fix this by adding a new proc prefix_id in lib/gdb.exp, and using it in the
test-case.
Tested on x86_64-linux.
|
|
When running test-case gdb.dwarf2/dw2-lines.exp with target board -unix/-m32,
we run into another instance of PR28383, where the dwarf assembler generates
64-bit relocations which are not supported by the 32-bit assembler:
...
dw2-lines-dw.S: Assembler messages:^M
outputs/gdb.dwarf2/dw2-lines/dw2-lines-dw.S:76: Error: \
cannot represent relocation type BFD_RELOC_64^M
...
Fix this by using _op_offset in _line_finalize_header.
Tested on x86_64-linux.
|
|
Before commit 3b6acaee895 "Update more calls to add_prefix_cmd" we had the
following output for "show logging file":
...
$ gdb -q -batch -ex "set trace-commands on" \
-ex "set logging off" \
-ex "show logging file" \
-ex "set logging on" \
-ex "show logging file"
+set logging off
+show logging file
Future logs will be written to gdb.txt.
+set logging on
+show logging file
Currently logging to "gdb.txt".
...
After that commit we have instead:
...
+set logging off
+show logging file
The current logfile is "gdb.txt".
+set logging on
+show logging file
The current logfile is "gdb.txt".
...
Before the commit, whether logging is enabled or not can be deduced from the
output of the command. After the commit, the message is unified and it's no
longer clear whether logging is enabled or not.
Fix this by:
- adding a new command "show logging enabled"
- adding a corresponding new command "set logging enabled on/off"
- making the commands "set logging on/off" deprecated aliases of the
"set logging enabled on/off" command.
Update the docs and testsuite to use "set logging enabled". Mention the new
and deprecated commands in NEWS.
Tested on x86_64-linux.
|
|
I noticed a new gcc option -gdwarf64 and tried it out (using gcc 11.2.1).
With a test-case hello.c:
...
int
main (void)
{
printf ("hello\n");
return 0;
}
...
compiled like this:
...
$ gcc -g -gdwarf64 ~/hello.c
...
I ran into:
...
$ gdb -q -batch a.out
DW_FORM_line_strp pointing outside of .debug_line_str section \
[in module a.out]
...
Debugging gdb revealed that the string offset is:
...
(gdb) up
objfile=0x182ab70, str_offset=1378684502312,
form_name=0xeae9b5 "DW_FORM_line_strp")
at src/gdb/dwarf2/section.c:208
208 error (_("%s pointing outside of %s section [in module %s]"),
(gdb) p /x str_offset
$1 = 0x14100000128
(gdb)
...
which is read when parsing a .debug_line entry at 0x1e0.
Looking with readelf at the 0x1e0 entry, we have:
...
The Directory Table (offset 0x202, lines 2, columns 1):
Entry Name
0 (indirect line string, offset: 0x128): /data/gdb_versions/devel
1 (indirect line string, offset: 0x141): /home/vries
...
which in a hexdump looks like:
...
0x00000200 1f022801 00004101 00000201 1f020f02
...
What happens is the following:
- readelf interprets the DW_FORM_line_strp reference to .debug_line_str as
a 4 byte value, and sees entries 0x00000128 and 0x00000141.
- gdb instead interprets it as an 8 byte value, and sees as first entry
0x0000014100000128, which is too big so it bails out.
AFAIU, gdb is wrong. It assumes DW_FORM_line_strp is 8 bytes on the basis
that the corresponding CU is 64-bit DWARF. However, the .debug_line
contribution has it's own initial_length field, and encodes there that it's
32-bit DWARF.
Fix this by using the correct offset size for DW_FORM_line_strp references
in .debug_line.
Note: the described test-case does trigger this complaint (both with and
without this patch):
...
$ gdb -q -batch -iex "set complaints 10" a.out
During symbol reading: intermixed 32-bit and 64-bit DWARF sections
...
The reason that the CU has 64-bit dwarf is because -gdwarf64 was passed to
gcc. The reason that the .debug_line entry has 32-bit dwarf is because that's
what gas generates. Perhaps this is complaint-worthy, but I don't think it
is wrong.
Tested on x86_64-linux, using native and target board dwarf64.exp.
|
|
The v5 section version for .debug_line has:
- two new fields address_size and segment_selector_size
- a different way to encode the directory and filename tables.
Add support for this in the dwarf assembler.
For now, make the v5 directory and filename tables work with the v4 type of
specification in the test-cases by adding duplicate entries at position 0.
This will need to be properly fixed with an intrusive fix that changes how
directory and filename entries are specified in the test-cases, f.i:
...
set diridx [include_dir "${srcdir}/${subdir}"]
set fileidx [file_name "$srcfile" $diridx]
...
Tested on x86_64-linux.
|
|
Rather than generate dwarf immediately in procs include_dir and file_name,
postpone generation and store the data in variables. Then handle the
generation in a new proc _line_finalize_header.
Tested on x86-64-linux.
|
|
The .debug_line header got a new field in v4:
maximum_operations_per_instruction.
Generate this field in the dwarf assembler, for now hardcoding the value to 1,
meaning non-VLIW.
Tested on x86_64-linux.
|
|
Add a new test-case gdb.dwarf2/dw2-lines.exp that tests various .debug_line
sections.
Tested on x86_64-linux.
|
|
Currently, for each MACRO_AT_range or MACRO_AT_func in dwarf assembly the
following is done:
- $srcdir/$subdir/$srcfile is compiled to an executable using
flags "debug"
- a new gdb instance is started
- the new executable is loaded.
This is inefficient, because the executable is identical within the same
Dwarf::assemble call.
Share the gdb instance in the same Dwarf::assemble invocation, which speeds
up a make check with RUNTESTFLAGS like this to catch all dwarf assembly
test-cases:
...
rtf=$(echo $(cd src/gdb/testsuite; find gdb.* -type f -name "*.exp" \
| xargs grep -l Dwarf::assemble))
...
from:
...
real 1m39.916s
user 1m25.668s
sys 0m21.377s
...
to:
...
real 1m29.512s
user 1m17.316s
sys 0m19.100s
...
Tested on x86_64-linux.
|
|
On OBS I ran into:
...
PASS: gdb.mi/mi-var-cp.exp: run to mi-var-cp.cc:81 (set breakpoint)
UNRESOLVED: gdb.mi/mi-var-cp.exp: unable to start target
...
followed by 81 FAILs and two more UNRESOLVEDs.
I didn't manage to reproduce this, but I did notice that the initial
problem causing the UNRESOLVED caused all subsequent UNRESOLVEDs and FAILs.
I emulated the problem by commenting out the send_gdb "run\n" in
mi_run_cmd_full.
Fix this by:
- handling mi_run_cmd failure in mi_get_inline_test
- handling mi_run_inline_test failure in gdb.mi/mi-var-cp.exp, and
other test-cases using mi_get_inline_test
Tested on x86_64-linux.
|
|
When running test-case gdb.dwarf2/loc-sec-offset.exp with target board -m32,
I run into:
...
builtin_spawn -ignore SIGHUP gcc -fno-stack-protector -m32 \
-fdiagnostics-color=never -c -o loc-sec-offset-dw641.o \
loc-sec-offset-dw64.S^M
as: loc-sec-offset-dw641.o: unsupported relocation type: 0x1^M
loc-sec-offset-dw64.S: Assembler messages:^M
loc-sec-offset-dw64.S:29: Error: cannot represent relocation type \
BFD_RELOC_64^M
...
Looking at line 29, we have:
...
.8byte .Labbrev1_begin /* Abbrevs */
...
It would be nice if the assembler could handle this somehow. But I guess
it's not unreasonable that an assembler for a 32-bit architecture will object
to handling 64-bit labels.
Instead, work around this in the dwarf assembler by emitting:
...
.4byte .Labbrev1_begin /* Abbrevs (lsw) */
.4byte 0 /* Abbrevs (msw) */
...
Tested on x86_64-linux with target board unix/-m32.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28383
|
|
When the code to handle DW_LLE_start_end was added (as part of some
DWARF 5 work), it was written to add the base address. However, this
seems incorrect -- the DWARF standard describes this as an address,
not an offset from the base address.
This patch changes a couple of spots in dwarf2/loc.c to fix this
problem. It then changes decode_debug_loc_addresses to return
DEBUG_LOC_OFFSET_PAIR instead, which preserves the previous semantics.
This only showed up on the RISC-V target internally, due to the
combination of DWARF 5 and a newer version of GCC. I've updated a
couple of existing loclists test cases to demonstrate the bug.
|
|
We see some additional failures when running the testsuite against a GDB
compiled with ASan, compared to a GDB compiled without ASan. Some of
them are caused by the memory leak report shown by the GDB process when
it exits, and the fact that it makes it exit with a non-zero exit code.
I generally try to remember to set ASAN_OPTIONS=detect_leaks=0 in my
environment when running the tests, but I don't always do it. I think
it would be nice if the testsuite did it. I don't see any use to have
leak detection when running the tests. That is, unless we ever have a
test that ensures GDB doesn't leak memory, which isn't going to happen
any time soon.
Here are some tests I found that were affected by this:
gdb.base/batch-exit-status.exp
gdb.base/many-headers.exp
gdb.base/quit.exp
gdb.base/with-mf.exp
gdb.dwarf2/gdb-add-index.exp
gdb.dwarf2/gdb-add-index-symlink.exp
gdb.dwarf2/imported-unit-runto-main.exp
Change-Id: I784c7df8a13979eb96587f735c1d33ba2cc6e0ca
|
|
Add .debug_loc support in the dwarf assembler, and use it in new test-case
gdb.dwarf2/loc-sec-offset.exp (which is based on
gdb.dwarf2/loclists-sec-offset.exp).
Tested on x86_64-linux.
|
|
When running with target board native-gdbserver, we run into a number of FAILs
due to use of the start command (and similar), which is not supported when
use_gdb_stub == 1.
Fix this by:
- requiring use_gdb_stub == 0 for the entire test-case, or
- guarding some tests in the test-case with use_gdb_stub == 0.
Tested on x86_64-linux.
|
|
Replace:
...
if { [ensure_gdb_index $binfile] == -1 } {
return -1
}
...
with:
...
require {ensure_gdb_index $binfile} != -1
...
and consequently, add a missing UNTESTED message.
Tested on x86_64-linux, both with native and target board readnow.
|
