| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
After this commit the gcc_compiled global is no longer exported from
lib/gdb.exp. In theory we could switch over all uses of gcc_compiled
to instead call test_compiler_info directly, however, I have instead
added a new proc to gdb.exp: 'is_c_compiler_gcc'. I've then updated
the testsuite to call this proc instead of using the global.
Having a new proc specifically for this task means that we have a
single consistent pattern for detecting gcc. By wrapping this logic
within a proc that calls test_compiler_info, rather than using the
global, means that test scripts don't need to call get_compiler_info
before they read the global, simply calling the new proc does
everything in one go.
As a result I've been able to remove the get_compiler_info calls from
all the test scripts that I've touched in this commit.
In some of the tests e.g. gdb.dwarf2/*.exp, the $gcc_compiled flag was
being checked at the top of the script to decide if the whole script
should be skipped or not. In these cases I've called the new proc
directly and removed all uses of gcc_compiled.
In other cases, e.g. most of the gdb.base scripts, there were many
uses of gcc_compiled. In these cases I set a new global gcc_compiled
near the top of the script, and leave the rest of the script
unchanged.
There should be no changes in what is tested after this commit.
|
|
If GDB, GDBserver, a testcase program, Valgrind, etc. unexpectedly
crash while running the GDB testsuite, and you've setup your machine
such that core files are dumped in the current directory instead of
being shoved somewhere by abrt, apport, or similar (as you should for
proper GDB testing), you'll end up with an unexpected core file in the
$build/gdb/testsuite/ directory.
It can happen that GDB, GDBserver, etc. even crashes _after_ gdb_exit,
during teardown, and thus such a crash won't be noticed by looking at
the gdb.sum file at all. This commit aims at improving that, by
including a new "unexpected core files" line in the testrun summary.
For example, here's what I get on x86-64 Ubuntu 20.04, with this
patch:
=== gdb Summary ===
# of unexpected core files 12 << new info
# of expected passes 107557
# of unexpected failures 35
# of expected failures 77
# of unknown successes 2
# of known failures 114
# of untested testcases 31
# of unsupported tests 139
I have my core pattern setup like this:
$ cat /proc/sys/kernel/core_pattern
core.%e.%p.%h.%t
That's:
%e: executable filename
%p: pid
%h: hostname
%t: UNIX time of dump
and so I get these core files:
$ ls -1 testsuite/core.*
testsuite/core.connect-with-no.216191.nelson.1656002431
testsuite/core.connect-with-no.217729.nelson.1656002431
testsuite/core.gdb.194247.nelson.1656002423
testsuite/core.gdb.226014.nelson.1656002435
testsuite/core.gdb.232078.nelson.1656002438
testsuite/core.gdb.352268.nelson.1656002441
testsuite/core.gdb.4152093.nelson.1656002337
testsuite/core.gdb.4154515.nelson.1656002338
testsuite/core.gdb.4156668.nelson.1656002339
testsuite/core.gdb.4158871.nelson.1656002341
testsuite/core.gdb.468495.nelson.1656002444
testsuite/core.vgdb.4192247.nelson.1656002366
where we can see that GDB crashed a number of times, but also
Valgrind's vgdb, and a couple testcase programs. Neither of which is
good.
If your core_pattern is just "core" (but why??), then I guess that you
may end up with just a single core file in testsuite/. Still, that is
one core file too many.
Above, we see a couple cores for "connect-with-no", which are the
result of gdb.server/connect-with-no-symbol-file.exp. This is a case
mentioned above -- while the program crashed, that happens during
testcase teardown, and it goes unnoticed (without this commit) by
gdb.sum results. Vis:
$ make check TESTS="gdb.server/connect-with-no-symbol-file.exp"
...
=== gdb Summary ===
# of unexpected core files 2
# of expected passes 8
...
$
The tests fully passed, but still the testcase program crashed
somehow:
$ ls -1 testsuite/core.*
testsuite/core.connect-with-no.941561.nelson.1656003317
testsuite/core.connect-with-no.941682.nelson.1656003317
Against --target_board=native-extended-gdbserver it's even worse. I
get:
# of unexpected core files 26
and note that when GDBserver hits an assertion failure, it exits with
error, instead of crashing with SIGABRT. I think that should be
changed, at least on development builds, but that would be for another
patch. After such patch, I suspect the number of unexpected cores
will be higher, as there are likely teardown GDBserver assertions that
we're not noticing.
I decided to put this new info in the "gdb Summary" section, as that's
a place people already are used to looking at, either when looking at
the tail of gdb.sum, or when diffing gdb.sum files, and we've already
extended this section before, to include the count of DUPLICATE and
PATH problems, so there's precedent.
Implementation-wise, the new line is appended after DejaGnu is
finished, with a shell script that is invoked by the Makefile. It is
done this way so that serial and parallel testing work the same way.
My initial cut at an implementation was in TCL, straight in
testsuite/lib/check-test-names.exp, where DUPLICATES and PATH are
handled, like so:
@@ -148,6 +159,10 @@ namespace eval ::CheckTestNames {
$counts(paths,$which)
maybe_show_count "# of duplicate test names\t" \
$counts(duplicates,$which)
+
+ set cores [glob -nocomplain -directory $::objdir core*]
+ maybe_show_count "# of unexpected core files\t" \
+ [llength $cores]
}
But that would only work for serial testing, as in parallel testing,
the final gdb.sum is generated by aggregating the results of all the
individual gdb.sum files, and dg-extract-results.sh doesn't know about
our new summary line. And I don't think that dg-extract-results.sh
should be taught about it, since the count of core files is not
something that we want to count many times, once per testcase, and
then add up the subcounts at the end. Every time we count the core
files, we're already counting the final count.
I considered using the Tcl implementation in serial mode, and the
script approach for parallel testing, but that has the obvious
downside of implementing and maintaining the same thing twice. In the
end, I settled on the script approach for serial mode too, which
requires making the "check-single" rule print the tail end of the
gdb.sum file, with a side effect being that if you look at the
terminal after a run (instead of at the gdb.sum file), you'll see the
"gdb Summary" section twice, once without the unexpected core lines
printed, and then another with. IMO, this isn't an issue; when
testing in parallel mode, if you look at the terminal after "make -jN
check", you'll also see multiple "gdb Summary" sections printed.
Change-Id: I190b8d41856d49ad143854b6e3e6ccd7caa04491
|
|
After a testrun, I noticed that I have some kernel-produced cores for
testcase programs, under build/gdb/testsuite/, which shouldn't be
there:
$ ls -1 testsuite/core.*
testsuite/core.annota1.1274351.nelson.1656004407
testsuite/core.annota3.1288474.nelson.1656004414
testsuite/core.exitsignal.1240674.nelson.1656004391
I have my core pattern setup like this:
$ cat /proc/sys/kernel/core_pattern
core.%e.%p.%h.%t
That's:
%e: executable filename
%p: pid
%h: hostname
%t: UNIX time of dump
so it's easy to tell which program produced the core from the core
file name.
From above, we can tell that the corresponding testcases are
gdb.base/annota1.exp, gdb.base/annota3.exp and
gdb.base/exitsignal.exp.
At least gdb.base/annota1.exp and gdb.base/annota3.exp have code in
them to delete the core file. However, that isn't working for me,
because said code only looks for cores named exactly either "core" or
"core.PID", and my core_pattern doesn't match that.
Another issue I noticed, is that I have not been running
gdb.base/bigcore.exp, for a similar reason. I get:
Program terminated with signal SIGABRT, Aborted.
The program no longer exists.
(gdb) PASS: gdb.base/bigcore.exp: signal SIGABRT
UNTESTED: gdb.base/bigcore.exp: can't generate a core file
But I actually have a core file under the testcase's output dir:
$ find . -name "core.*"
./testsuite/outputs/gdb.base/bigcore/core.bigcore.2306705.nelson.1656005213
$
This commit fixes these things, by adding a find_core_file routine
that searches core files in a way that works with my core pattern as
well. This then also adds a convenience remove_core routine as a
wrapper around find_core_file that removes the found core file.
In addition, it changes some testcases that expect to have their
program dump core, to switch the inferior's cwd to the testcase's
output dir, so that the core is dumped there instead of in
build/gdb/testsuite/. Some testcases were already doing that, but not
all. The idea is that any core file dumped in build/gdb/testsuite/ is
an unexpected core file. The next patch will add a count of such
unexpected core files to gdb.sum.
Another change is that the directory changing is now done with "set
cwd" instead of with "cd". "set cwd" only affects the inferior cwd,
while "cd" affects GDB's cwd too. By using "set cwd" instead of "cd",
if GDB dumps core in these testcases, the GDB core dump will still end
up in build/gdb/testsuite/, and can thus be detected as an unexpected
core.
Change-Id: I45068f21ffd4814350aaa8a3cc65cad5e3107607
|
|
When testing on openSUSE Leap 15.4 I ran into this FAIL:
...
FAIL: gdb.arch/i386-mpx-map.exp: NULL address of the pointer
...
and likewise for all the other mpx tests.
The problem is that have_mpx is supposed to return 0, but it doesn't because
it tries to match this output:
...
builtin_spawn -ignore SIGHUP temp/20294/have_mpx-2-20294.x^M
No MPX support^M
No MPX support^M
...
using:
...
&& ![string equal $output "No MPX support\r\n"]]
...
Fix this by matching using a regexp instead.
Tested on x86_64-linux.
|
|
On openSUSE Leap 42.3 with python 3.4, I run into:
...
(gdb) python import pygments^M
Traceback (most recent call last):^M
File "<string>", line 1, in <module>^M
ImportError: No module named 'pygments'^M
Error while executing Python code.^M
(gdb) FAIL: gdb.base/style.exp: python import pygments
ERROR: unexpected output from python import
...
because gdb_py_module_available doesn't handle the single quotes around the
module name in the ImportError.
Fix this by allowing the single quotes.
Tested on x86_64-linux.
|
|
Since pretty much forever the get_compiler_info function has included
these lines:
# Most compilers will evaluate comparisons and other boolean
# operations to 0 or 1.
uplevel \#0 { set true 1 }
uplevel \#0 { set false 0 }
These define global variables true (to 1) and false (to 0).
It seems odd to me that these globals are defined in
get_compiler_info, I guess maybe the original thinking was that if a
compiler had different true/false values then we would detect it there
and define true/false differently.
I don't think we should be bundling this logic into get_compiler_info,
it seems weird to me that in order to use $true/$false a user needs to
first call get_compiler_info.
It would be better I think if each test script that wants these
variables just defined them itself, if in the future we did need
different true/false values based on compiler version then we'd just
do:
if { [test_compiler_info "some_pattern"] } {
# Defined true/false one way...
} else {
# Defined true/false another way...
}
But given the current true/false definitions have been in place since
at least 1999, I suspect this will not be needed any time soon.
Given that the definitions of true/false are so simple, right now my
suggestion is just to define them in each test script that wants
them (there's not that many). If we ever did need more complex logic
then we can always add a function in gdb.exp that sets up these
globals, but that seems overkill for now.
There should be no change in what is tested after this commit.
|
|
The previous patch that introduced the arm_cc_for_target procedure
moved the ARM_CC_FOR_TARGET global check to that procedure, but forgot
to tell tcl that ARM_CC_FOR_TARGET is a global. As a result,
specifying ARM_CC_FOR_TARGET on the command line actually does
nothing. This fixes it.
Change-Id: I4e33b7633fa665e2f7b8f8c9592a949d74a19153
|
|
After this commit:
commit 44d469c5f85a4243462b8966722dafa62b602bf5
Date: Tue May 31 16:43:44 2022 +0200
gdb/testsuite: add Fortran compiler identification to GDB
Some regressions were noticed:
https://sourceware.org/pipermail/gdb-patches/2022-May/189673.html
The problem is associated with how compiler_info variable is cached
between calls to get_compiler_info.
Even before the above commit, get_compiler_info supported two
language, C and C++. Calling get_compiler_info would set the global
compiler_info based on the language passed as an argument to
get_compiler_info, and, in theory, compiler_info would not be updated
for the rest of the dejagnu run.
This obviously is slightly broken behaviour. If the first call to
get_compiler_info was for the C++ language then compiler_info would be
set based on the C++ compiler in use, while if the first call to
get_compiler_info was for the C language then compiler_info would be
set based on the C compiler.
This probably wasn't very noticable, assuming a GCC based test
environment then in most cases the C and C++ compiler would be the
same version.
However, if the user starting playing with CC_FOR_TARGET or
CXX_FOR_TARGET, then they might not get the behaviour they expect.
Except, to make matters worse, most of the time, the user probably
would get the behaviour they expected .... except when they didn't!
I'll explain:
In gdb.exp we try to avoid global variables leaking between test
scripts, this is done with the help of the two procs
gdb_setup_known_globals and gdb_cleanup_globals. All known globals
are recorded before a test script starts, and then, when the test
script ends, any new globals are deleted.
Normally, compiler_info is only set as a result of a test script
calling get_compiler_info or test_compiler_info. This means that the
compiler_info global will not exist when the test script starts, but
will exist when the test script end, and so, the compiler_info
variable is deleted at the end of each test.
This means that, in reality, the compiler_info is recalculated once
for each test script, hence, if a test script just checks on the C
compiler, or just checks on the C++ compiler, then compiler_info will
be correct and the user will get the behaviour they expect.
However, if a single test script tries to check both the C and C++
compiler versions then this will not work (even before the above
commit).
The situation is made worse be the behaviour or the load_lib proc.
This proc (provided by dejagnu) will only load each library once.
This means that if a library defines a global, then this global would
normally be deleted at the end of the first test script that includes
the library.
As future attempts to load the library will not actually reload it,
then the global will not be redefined and would be missing for later
test scripts that also tried to load that library.
To work around this issue we override load_lib in gdb.exp, this new
version adds all globals from the newly loaded library to the list of
globals that should be preserved (not deleted).
And this is where things get interesting for us. The library
trace-support.exp includes calls, at the file scope, to things like
is_amd64_regs_target, which cause get_compiler_info to be called.
This means that after loading the library the compiler_info global is
defined.
Our override of load_lib then decides that this new global has to be
preserved, and adds it to the gdb_persistent_globals array.
From that point on compiler_info will never be recomputed!
This commit addresses all the caching problems by doing the following:
Change the compiler_info global into compiler_info_cache global. This
new global is an array, the keys of this array will be each of the
supported languages, and the values will be the compiler version for
that language.
Now, when we call get_compiler_info, if the compiler information for
the specific language has not been computed, then we do that, and add
it to the cache.
Next, compiler_info_cache is defined by calling
gdb_persistent_global. This automatically adds the global to the list
of persistent globals. Now the cache will not be deleted at the end
of each test script.
This means that, for a single test run, we will compute the compiler
version just once for each language, this result will then be cached
between test scripts.
Finally, the legacy 'gcc_compiled' flag is now only set when we call
get_compiler_info with the language 'c'. Without making this change
the value of 'gcc_compiled' would change each time a new language is
passed to get_compiler_info. If the last language was e.g. Fortran,
then gcc_compiled might be left false.
|
|
Now that get_compiler_info might actually fail (if the language is not
handled), then we should try to handle this failure better in
test_compiler_info.
After this commit, if get_compiler_info fails then we will return a
suitable result depending on how the user called test_compiler_info.
If the user does something like:
set version [test_compiler_info "" "unknown-language"]
Then test_compiler_info will return an empty string. My assumption is
that the user will be trying to match 'version' against something, and
the empty string hopefully will not match.
If the user does something like:
if { [test_compiler_info "some_pattern" "unknown-language"] } {
....
}
Then test_compiler_info will return false which seems the obvious
choice.
There should be no change in the test results after this commit.
|
|
This commit is a minor cleanup for the two functions (in gdb.exp)
get_compiler_info and test_compiler_info.
Instead of using the empty string as the default language, and just
"knowing" that this means the C language. Make this explicit. The
language argument now defaults to "c" if not specified, and the if
chain in get_compiler_info that checks the language not explicitly
handles "c" and gives an error for unknown languages.
This is a good thing, now that the API appears to take a language, if
somebody does:
test_compiler_info "xxxx" "rust"
to check the version of the rust compiler then we will now give an
error rather than just using the C compiler and leaving the user
having to figure out why they are not getting the results they
expect.
After a little grepping, I think the only place we were explicitly
passing the empty string to either get_compiler_info or
test_compiler_info was in gdb_compile_shlib_1, this is now changed to
pass "c" as the default language.
There should be no changes to the test results after this commit.
|
|
We don't need to call get_compiler_info before calling
test_compiler_info; test_compiler_info includes a call to
get_compiler_info.
This commit cleans up lib/gdb.exp and lib/dwarf.exp a little by
removing some unneeded calls to get_compiler_info. We could do the
same cleanup throughout the testsuite, but I'm leaving that for
another day.
There should be no change in the test results after this commit.
|
|
The procedure gcc_major_version was earlier using the global variable
compiler_info to retrieve gcc's major version. This is discouraged and
(as can be read in a comment in compiler.c) compiler_info should be
local to get_compiler_info and test_compiler_info.
The preferred way of getting the compiler string is via calling
test_compiler_info without arguments. Gcc_major_version was changed to
do that.
|
|
On Aarch64, you can set ARM_CC_FOR_TARGET to point to the 32-bit
compiler to use when testing gdb.multi/multi-arch.exp and
gdb.multi/multi-arch-exec.exp. If you don't set it, then those
testcases don't run.
I guess that approximately nobody remembers to set ARM_CC_FOR_TARGET.
This commit adds a fallback. If ARM_CC_FOR_TARGET is not set, and
testing for Linux, try arm-linux-gnueabi-gcc,
arm-none-linux-gnueabi-gcc, arm-linux-gnueabihf-gcc as 32-bit
compilers, making sure that the produced executable runs on the target
machine before claiming that the compiler produces useful executables.
Change-Id: Iefe5865d5fc84b4032eaff7f4c5c61582bf75c39
|
|
There was already a similar functionality for the GDBInfoModuleSymbols.
This just extends the GDBInfoSymbols. We will use this feature in a
later commit to make a testcase less GNU specific and more flexible for
other compilers.
Namely, in gdb.fortran/info-types.exp currenlty
GDBInfoSymbols::check_entry is used to verify and test the output of the
info symbols command. The test, however was written with gfortran as a
basis and some of the tests are not fair with e.g. ifx and ifort as
they test for symbols that are not actually required to be emitted. The
lines
GDBInfoSymbols::check_entry "${srcfile}" "" "${character1}"
and
GDBInfoSymbols::check_entry "${srcfile}" "37" "Type s1;"
check for types that are either not used in the source file (character1)
or should not be emitted by the compiler at global scope (s1) thus no
appearing in the info symbols command. In order to fix this we will
later use the newly introduced check_optional_entry over check_entry.
|
|
In order for ifx and ifort to emit all debug entries, even for unused
parameters in modules we have to define the '-debug-parameters all' flag.
This commit adds it to the ifx-*/ifort-* specific flags in gdb.exp.
|
|
The name for icx and icpx in the testsuite was earlier set to 'intel-*'
by the compiler identification. This commit changes this to 'icx-*'.
Note, that currently these names are not used within the testsuite so no
tests have to be adapted here.
|
|
This commit adds a separate Fortran compiler identification mechanism to
the testsuite, similar to the existing one for C/C++. Before this
change, the options and version for the Fortran compiler specified when
running the testsuite with F90_FOR_TARGET set, was detected via its
respective C compiler. So running the testsuite as
make check TEST=gdb.fortran/*.exp CC_FOR_TARGET=gcc F90_FOR_TARGET=ifx
or even
make check TEST=gdb.fortran/*.exp F90_FOR_TARGET=ifx
would use the gcc compiler inside the procedures get_compiler_info and
test_compiler_info to identify compiler flags and the compiler version.
This could sometimes lead to unpredictable outputs. It also limited
testsuite execution to combinations where C and Fortran compiler would
come from the same family of compiers (gcc/gfortran, icc/ifort, icx/ifx,
clang/flang ..). This commit enables GDB to detect C and Fortran
compilers independently of each other.
As most/nearly all Fortran compilers have a mechanism for preprocessing
files in a C like fashion we added the exact same meachnism that already
existed for C/CXX. We let GDB preprocess a file with the compilers
Fortran preprocessor and evaluate the preprocessor defined macros in that
file.
This enables GDB to properly run heterogeneous combinations of C and
Fortran compilers such as
CC_FOR_TARGET='gcc' and F90_FOR_TARGET='ifort'
or enables one to run the testsuite without specifying a C compiler as in
make check TESTS=gdb.fortran/*.exp F90_FOR_TARGET='ifx'
make check TESTS=gdb.fortran/*.exp F90_FOR_TARGET='flang'
On the other hand this also requires one to always specify a
identification mechanism for Fortran compilers in the compiler.F90 file.
We added identification for GFORTRAN, FLANG (CLASSIC and LLVM) IFX,
IFORT, and ARMFLANG for now.
Classic and LLVM flang were each tested with their latest releases on
their respective release pages. Both get recognized by the new compiler
identification and we introduced the two names flang-classic and
flang-llvm to distinguish the two. While LLVM flang is not quite mature
enough yet for running the testsuite we still thought it would be a good
idea to include it already. For this we added a case for the fortran_main
procedure. LLVM flang uses 'MAIN__' as opposed to classic flang which
uses 'MAIN_' here.
We did not have the possibility to test ARMFLANG - the versioning scheme
here was extracted from its latest online documentation.
We changed the test_compiler_info procedure to take another optional
argument, the language string, which will be passed though to the
get_compiler_info procedure. Passing 'f90' or 'c++' here will then
trigger the C++/Fortran compiler identification within
get_compiler_info. The latter procedure was extended to also handle
the 'f90' argument (similarly to the already existing 'c++' one).
Co-authored-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
|
|
The procedure gdb_compile queries its options via
[lsearch -exact $options getting_compiler_info]
to check whether or not it was called in with the option
getting_compiler_info. If it was called with this option it would
preprocess some test input to try and figure out the actual compiler
version of the compiler used. While doing this we cannot again try to
figure out the current compiler version via the 'getting_compiler_info'
option as this would cause infinite recursion. As some parts of the
procedure do recursively test for the compiler version to e.g. set
certain flags, at several places gdb_compile there are checks for the
getting_compiler_info option needed.
In the procedure, there was already a variable 'getting_compiler_info'
which was set to the result of the 'lsearch' query and used instead of
again and again looking for getting_compiler_info in the procedure
options. But, this variable was actually set too late within the code.
This lead to a mixture of querying 'getting_compiler_info' or
doing an lserach on the options passed to the procedure.
I found this inconsistent and instead moved the variable
getting_compiler_info to the front of the procedure. It is set to true
or false depending on whether or not the argument is found in the
procedure's options (just as before) and queried instead of doing an
lsearch on the procedure options in the rest of the procedure.
|
|
Newer Intel compilers emit their dwarf type name in a slightly different
format. Therefore, this needs adjustment to make more tests pass in the
Fortran testsuite.
Co-authored-by: Abdul Basit Ijaz <abdul.b.ijaz@intel.com>
Co-authored-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
|
|
The '-J' option is not supported in Intel compilers (ifx and ifort).
The Intel version of the flag is '-module' which serves the same purpose.
|
|
The last uses of the F77_FOR_TARGET via passing f77 to GDB's compile
procedure were removed in this commit
commit 0ecee54cfd04a60e7ca61ae07c72b20e21390257
Author: Tom Tromey <tromey@redhat.com>
Date: Wed Jun 29 17:50:47 2011 +0000
over 10 years ago. The last .f files in the testsuite by now are all
being compiled by passing 'f90' to the GDB compile, thus only actually
using F90_FOR_TARGET (array-element.f, block-data.f, subarray.f).
Gfortran in this case is backwards compatible with most f77 code as
claimed on gcc.gnu.org/fortran.
The reason we'd like to get rid of this now is, that we'll be
implementing a Fortran compiler identification mechanism, similar to the
C/Cpp existing ones. It would be using the Fortran preprocessor macro
defines to identify the Fortran compiler version at hand. We found it
inconsequent to only implement this for f90 but, on the other hand, f77
seems deprecated. So, with this commit we remove the remaining lines for
its support.
|
|
The previous patch to add -prompt/-lbl to gdb_test introduced a
regression: Before, you could specify an explicit empty message to
indicate you didn't want to PASS, like so:
gdb_test COMMAND PATTERN ""
After said patch, gdb_test no longer distinguishes
no-message-specified vs empty-message, so tests that previously would
be silent on PASS, now started emitting PASS messages based on
COMMAND. This in turn introduced a number of PATH/DUPLICATE
violations in the testsuite.
This commit fixes all the regressions I could see.
This patch uses the new -nopass feature introduced in the previous
commit, but tries to avoid it if possible. Most of the patch fixes
DUPLICATE issues the usual way, of using with_test_prefix or explicit
unique messages.
See previous commit's log for more info.
In addition to looking for DUPLICATEs, I also looked for cases where
we would now end up with an empty message in gdb.sum, due to a
gdb_test being passed both no message and empty command. E.g., this
in gdb.ada/bp_reset.exp:
gdb_run_cmd
gdb_test "" "Breakpoint $decimal, foo\\.nested_sub \\(\\).*"
was resulting in this in gdb.sum:
PASS: gdb.ada/bp_reset.exp:
I fixed such cases by passing an explicit message. We may want to
make such cases error out.
Tested on x86_64 GNU/Linux, native and native-extended-gdbserver. I
see zero PATH cases now. I get zero DUPLICATEs with native testing
now. I still see some DUPLICATEs with native-extended-gdbserver, but
those were preexisting, unrelated to the gdb_test change.
Change-Id: I5375f23f073493e0672190a0ec2e847938a580b2
|
|
The previous patch to add -prompt/-lbl to gdb_test introduced a
regression: Before, you could specify an explicit empty message to
indicate you didn't want to PASS, like so:
gdb_test COMMAND PATTERN ""
After said patch, gdb_test no longer distinguishes
no-message-specified vs empty-message, so tests that previously would
be silent on PASS, now started emitting PASS messages based on
COMMAND. This in turn introduced a number of PATH/DUPLICATE
violations in the testsuite.
I think that not issuing a PASS should be restricted to only a few
cases -- namely in shared routines exported by gdb.exp, which happen
to use gdb_test internally. In tests that iterate an unknown number
of tests exercising some racy scenario. In the latter case, if we
emit PASSes for each iteration, we run into the situation where
different testsuite runs emit a different number of PASSes.
Thus, this patch preserves the current behavior, and, instead, adds a
new "-nopass" option to gdb_test and gdb_test_no_output. Compared to
the old way of supressing PASS with an empty message, this has the
advantage that you can specify a FAIL message that is distinct from
the command string, and, it's also more explicit.
Change-Id: I5375f23f073493e0672190a0ec2e847938a580b2
|
|
With check-read1 I run into:
...
[infrun] maybe_set_commit_resumed_all_targets: not requesting
commit-resumed for target native, no resumed threads^M
(gdb) FAIL: gdb.base/ui-redirect.exp: debugging: continue
[infrun] fetch_inferior_event: exit^M
...
The problem is that proc gdb_test doesn't pass down the -prompt option to proc
gdb_test_multiple, due to a typo making this lappend without effect:
...
set opts {}
lappend "-prompt $prompt"
...
Fix this by actually appending to opts.
Tested on x86_64-linux.
|
|
When execute the following command on LoongArch:
make check-gdb TESTS="gdb.base/async-shell.exp"
we can see the following message in gdb/testsuite/gdb.sum:
UNSUPPORTED: gdb.base/async-shell.exp: displaced stepping
modify support_displaced_stepping to support displaced stepping
on LoongArch.
With this patch:
PASS: gdb.base/async-shell.exp: run &
PASS: gdb.base/async-shell.exp: shell echo foo
PASS: gdb.base/async-shell.exp: interrupt
PASS: gdb.base/async-shell.exp: process stopped
I did the following tests that use support_displaced_stepping
with this patch on LoongArch, there is no failed testcases.
loongson@linux:~/gdb.git$ grep -r support_displaced_stepping gdb/testsuite/gdb.*
gdb/testsuite/gdb.arch/disp-step-insn-reloc.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.base/step-over-no-symbols.exp: if { $displaced != "off" && ![support_displaced_stepping] } {
gdb/testsuite/gdb.base/moribund-step.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.base/async-shell.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.base/inferior-died.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.base/step-over-syscall.exp: if {$displaced == "on" && ![support_displaced_stepping]} {
gdb/testsuite/gdb.mi/mi-watch-nonstop.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.mi/mi-ns-stale-regcache.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.mi/mi-nonstop.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.mi/mi-nsmoribund.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.mi/mi-nsintrall.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.mi/mi-nsthrexec.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.mi/mi-nonstop-exit.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.multi/watchpoint-multi.exp:if [support_displaced_stepping] {
gdb/testsuite/gdb.python/py-evthreads.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.threads/step-over-lands-on-breakpoint.exp: if { $displaced != "off" && ![support_displaced_stepping] } {
gdb/testsuite/gdb.threads/interrupt-while-step-over.exp: if { ${displaced-stepping} != "off" && ![support_displaced_stepping] } {
gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.exp: if { $displaced != "off" && ![support_displaced_stepping] } {
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
This teaches gdb_test to forward the -prompt and -lbl options to
gdb_test_multiple.
The option parsing is done with parse_args.
As a cleanup, instead of using llength and lindex to get at the
positional arguments, use lassign, and check whether the corresponding
variable is empty.
Convert gdb.base/ui-redirect.exp and gdb.xml/tdesc-reload.exp to use
gdb_test -prompt/-lbl instead of gdb_test_multiple as examples.
Change-Id: I243e1296d32c05a421ccef30b63d43a89eaeb4a0
|
|
gdb_test supports handling scenarios where GDB asks a question before
finishing handling some command. The full prototype of gdb_test is:
# gdb_test COMMAND PATTERN MESSAGE QUESTION RESPONSE
However, QUESTION is a question that GDB _may_ ask, not one that GDB
_must_ ask:
# QUESTION is a question GDB may ask in response to COMMAND, like
# "are you sure?"
# RESPONSE is the response to send if QUESTION appears.
If GDB doesn't raise the question, the test still passes.
I think that this is a misfeature. If GDB regresses and stops asking
a question, the testsuite won't notice. So I think that if a QUESTION
is specified, gdb_test should ensure it comes out of GDB.
Running the testsuite exposed a number of tests that pass
QUESTION/RESPONSE to GDB, but no question comes out. The previous
commits fixed them all, so this commit changes gdb_test's behavior.
A related issue is that gdb_test doesn't enforce that if you specify
QUESTION, that you also specify RESPONSE. I.e., you should pass 1, 2,
3, or 5 arguments to gdb_test, but never 4, or more than 5. Making
gdb_test detect bogus arguments actually regressed some testcases,
also all fixed in previous commits.
Change-Id: I47c39c9034e6a6841129312037a5ca4c5811f0db
|
|
When running test-case gdb.tui/scroll.exp, I get:
...
Box Dump (80 x 8) @ (0, 0):
0 $17 = 16
1 (gdb) p 17
2 $18 = 17
3 (gdb) p 18
4 $19 = 18
5 (gdb) p 19
6 $20 = 19
7 (gdb)
PASS: gdb.tui/scroll.exp: check cmd window in flip layout
...
but with check-read1 I get instead:
...
Box Dump (80 x 8) @ (0, 0):
0 (gdb) 15
1 (gdb) p 16
2 $17 = 16
3 (gdb) p 17
4 $18 = 17
5 (gdb) p 18
6 $19 = 18
7 (gdb) p 19
FAIL: gdb.tui/scroll.exp: check cmd window in flip layout
...
The "p 19" command is handled by Term::command, which sends the command and then
does Term::wait_for "^$gdb_prompt [string_to_regexp $cmd]", which:
- matches the line with "(gdb) p 19", and
- tries to match the following prompt "(gdb) "
The problem is that scrolling results in reissuing output before the "(gdb) p
19", and the second matching triggers on that. Consequently, wait_for no
longer translates gdb output into screen actions, and the screen does not
reflect the result of "p 19".
Fix this by using a new proc wait_for_region_contents, which in contrast to
wait_for can handle a multi-line regexp.
Tested on x86_64-linux with make targets check and check-read1.
|
|
When running test-case gdb.dwarf2/locexpr-data-member-location.exp with
target board unix/-fno-PIE/-no-pie/-m32 I run into:
...
(gdb) step^M
26 return 0;^M
(gdb) FAIL: gdb.dwarf2/locexpr-data-member-location.exp: step into foo
...
The problem is that the test-case tries to mimic some gdb_compile_shlib
behaviour using:
...
set flags {additional_flags=-fpic debug}
get_func_info foo $flags
...
but this doesn't work with the target board setting, because we end up doing:
...
gcc locexpr-data-member-location-lib.c -fpic -g -lm -fno-PIE -no-pie -m32 \
-o func_addr23029.x
...
while gdb_compile_shlib properly filters out the -fno-PIE -no-pie.
Consequently, the address for foo determined by get_func_info doesn't match
the actual address of foo.
Fix this by printing the address of foo using the result of gdb_compile_shlib.
|
|
After this previous commit I was thinking about the API of
mi_gdb_start. I felt that the idea of passing flags as separate
arguments and using 'args' to gather these into a list, though clever,
was not an intuitive API.
In this commit I modify mi_gdb_start so that it expects a single
argument, which should be a list of flags. Thus, where we previously
would have said:
mi_gdb_start separate-mi-tty separate-inferior-tty
We would now say:
mi_gdb_start { separate-mi-tty separate-inferior-tty }
However, it turns out we never actually call mi_gdb_start passing two
arguments in this way at all. We do in some places do this:
mi_gdb_start separate-inferior-tty
But that's fine, a single string like this works equally well as a
single item list, so this will not need updating.
There is also one place where we do this:
eval mi_gdb_start $start_ops
where $start_ops is a list that might contains 0, 1, or 2 items. The
eval here is used to expand the $start_ops list so mi_gdb_start sees
the list contents as separate arguments. In this case we just need to
drop the use of eval.
I think that the new API is more intuitive, but others might
disagree, in which case I can drop this change.
There should be no change in what is tested after this commit.
|
|
I learned about with_cwd today. I spotted a few spots that could use
it, to make the code more robust.
Change-Id: Ia23664cb827f25e79d31948e0c006a8dc61c33e1
|
|
Commit c67f4e538 ("gdb/testsuite: make gdb.ada/mi_prot.exp stop at
expected location") introduced some DUPLICATEs in MI tests using
mi_continue_to_line, for example:
DUPLICATE: gdb.ada/mi_ref_changeable.exp: mi_continue_to_line: set temporary breakpoint
These test names were previously differentiated by the location passed
to mi_continue_to_line. Since the location can contain a path, that
commit removed the location from the test name, in favor of a hardcoded
string "set temporary breakpoint", hence removing the differentiator.
mi_continue_to_line receives a "test" parameter, containing a test
name. Add a "with_test_prefix" with that name, so that all tests
recorded during mi_continue_to_line have this in their name.
mi_continue_to_line passes that "test" string to mi_get_stop_line, that
is a bit superfluous. mi_get_stop_line only uses that string in case of
failures (it doesn't record a pass if everything goes fine). Since it's
not crucial, just remove it, and adjust all callers.
Adjust three gdb.mi/mi-var-*.exp tests to use prefixes to differentiate
the multiple calls to mi_run_inline_test (which calls
mi_continue_to_line).
Change-Id: I511c6caa70499f8657b1cde37d71068d74d56a74
|
|
In a previous commit (b750766ac96: gdb/testsuite: Introduce and use
gdb_spawn_attach_cmdline), if gdb_spawn_attach_cmdline cannot have GDB
attach to the process because of ptrace restrictions (operation not
permitted), the proc issues UNTESTED. This should really be
UNSUPPORTED, as it is done in gdb_attach.
This patch fixes this oversight.
Change-Id: Ib87e33b9230f3fa7a85e06220ef4c63814b71f7d
|
|
Following a7e6a19e87f3d719ea23c65b580a6d9bca4ccab3 "gdb: testsuite: add
new gdb_attach to check "attach" command", this commit proposes to
introduce the gdb_spawn_attach_cmdline helper and use it in
gdb.base/attach.exp.
This helper starts GDB and adds the "--pid=$PID" argument.
Also note that both the original and new implementation use
gdb_spawn_with_cmdline_opts, which in the end uses default_gdb_spawn.
This makes sure that we use $INTERNAL_GDBFLAGS, which by default already
contain "-iex \"set height 0\" -iex \"set width 0\"". To avoid
repetition of those arguments, gdb_spawn_attach_cmdline does not repeat
those arguments.
To maintain a behavior similat to what gdb.base/attach.exp used to do,
gdb_spawn_attach_cmdline keeps the -quiet flag.
Tested on x86_64-gnu-linux
Change-Id: I1fdcdb71c86d9c5d34bb28fc86fac68bcec37358
|
|
DWARF 5
To support DWARF 5 in the DWARF assembler line tables, we currently copy
the first user-provided directory and the first user-provided files and
make them elements at indices 0 in the directory and file name tables.
That was a sufficient behavior at the time (see commit 44fda089397a
("[gdb/testsuite] Support .debug_line v5 in dwarf assembler")), but in
the following patches, I would need to have finer grained control on
what is generated exactly. For example, I'd like to generate a DWARF 5 line
table with just a single file and a single directory.
Get rid of this behavior, and implement what is suggested in
44fda089397a: make include_dir return the directory index that can be
used to refer to that directory entry (based on the DWARF version), and
use it afterwards.
Adjust dw2-lines.exp and dw2-prologue-end.exp accordingly. Their produced
DWARF5 binaries will change a bit, in that they will now have a single
directory and file, where they had two before. But it doesn't change
the expected GDB behavior.
Change-Id: I5459b16ac9b7f28c34c9693c35c9afd2ebb3aa3b
|
|
This test attempts to run until the line marked "STOP", which is at
prot.adb:34. It first runs until the "main" symbol, then tries to place
a breakpoint by line at line 34, without specifying the source file. When looking at the logs:
-break-insert -t 34^M
^done,bkpt={number="2",type="breakpoint",disp="del",enabled="y",addr="0x0000555555558a6c",func="adafinal",file="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_pro t/b~prot.adb",fullname="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_prot/b~prot.adb",line="44",thread-groups=["i1"],times="0",original-location="/home/simark/b uild/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_prot/b~prot.adb:34"}^M
... continues ...
*stopped,reason="breakpoint-hit",disp="del",bkptno="2",frame={addr="0x0000555555558a6c",func="adafinal",args=[],file="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/ mi_prot/b~prot.adb",fullname="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_prot/b~prot.adb",line="44",arch="i386:x86-64"},thread-id="1",stopped-threads="all",co re="8"^M
... we see that the breakpoint is placed in some generated file, not in
the test source file as we expect. The problem is that "b main" in Ada
does not place a breakpoint on the "Ada main", but on some symbol in a
generated source file. So when stopped at the "main" symbol, we are not
stopped in the file that contains the STOP marker at line 34.
The test passes anyway today, so it doesn't seem to matter that we are
stopped at an unexpected location. But it starts failing with this
patch [1], because b~prot.adb:34 happens to be between two functions, so
the breakpoint doesn't resolve.
Fix this by placing the breakpoint at "$srcfile:$line", which works
regardless of what is the current source file.
However, this ends up introducing a path in the test name. Modify
mi_tbreak and mi_continue_to_line to avoid that.
[1] https://sourceware.org/pipermail/gdb-patches/2022-April/187686.html
Change-Id: I742e2a9993046dcb5e30c64fe2ad920a363baf75
|
|
LLVM's lld linker doesn't have the "-Ttext-segment" option, but
"--image-base" can be used instead.
To centralize the logic of checking which option is supported, add the
text_segment option to gdb_compile. Change tests that are currently
using -Ttext-segment to use that new option instead.
This patch fixes only compilation error, for example:
Before:
$ make check TESTS="gdb.base/jit-elf.exp" RUNTESTFLAGS="CC_FOR_TARGET=clang LDFLAGS_FOR_TARGET=-fuse-ld=ld"
Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-elf.exp ...
gdb compile failed, clang-13: warning: -Xlinker -Ttext-segment=0x7000000: 'linker' input unused [-Wunused-command-line-argument]
After:
$ make check TESTS="gdb.base/jit-elf.exp" RUNTESTFLAGS="CC_FOR_TARGET=clang LDFLAGS_FOR_TARGET=-fuse-ld=ld"
Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-elf.exp ...
FAIL: gdb.base/jit-elf.exp: one_jit_test-1: continue to breakpoint: break here 1
FAIL: gdb.base/jit-elf.exp: one_jit_test-1: continue to breakpoint: break here 2
FAIL: gdb.base/jit-elf.exp: one_jit_test-2: continue to breakpoint: break here 1
FAIL: gdb.base/jit-elf.exp: one_jit_test-2: info function ^jit_function
FAIL: gdb.base/jit-elf.exp: one_jit_test-2: continue to breakpoint: break here 2
FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: continue to breakpoint: break here 1
FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach
FAIL: gdb.base/jit-elf.exp: PIE: one_jit_test-1: continue to breakpoint: break here 1
FAIL: gdb.base/jit-elf.exp: PIE: one_jit_test-1: continue to breakpoint: break here 2
=== gdb Summary ===
# of expected passes 26
# of unexpected failures 9
Change-Id: I3678c5c9bbfc2f80671698e28a038e6b3d14e635
|
|
The rust_compiler_version proc extracts the Rust compiler version from
the "rustc --version" output. For a beta compiler, the output looks
like:
rustc 1.60.0-beta.6 (7bccde197 2022-03-22)
This patch slightly relaxes the regexp -- removing a space -- so that
this can be understood by this proc.
|
|
On openSUSE Leap 15.3, mpx support has been disabled for m32, so I run into:
...
(gdb) run ^M
Starting program: outputs/gdb.arch/i386-mpx/i386-mpx ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
No MPX support^M
...
and eventually into all sort of fails in this and other mpx test-cases.
Fix this by detecting the "No MPX support" message in have_mpx.
Tested on x86_64-linux with target boards unix and unix/-m32.
|
|
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
|
