This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[PATCH v2] gdb/testsuite: Regenerate the testglue if it is not in path
- From: Shahab Vahedi <shahab dot vahedi at gmail dot com>
- To: gdb-patches at sourceware dot org
- Cc: Shahab Vahedi <shahab dot vahedi at gmail dot com>, Shahab Vahedi <shahab at synopsys dot com>, Tom Tromey <tom at tromey dot com>, Francois Bedard <fbedard at synopsys dot com>
- Date: Tue, 18 Feb 2020 12:51:41 +0100
- Subject: [PATCH v2] gdb/testsuite: Regenerate the testglue if it is not in path
- References: <20200211133710.6120-1-shahab.vahedi@gmail.com>
From: Shahab Vahedi <shahab@synopsys.com>
For running the DejaGnu tests, some esoteric configurations
may require a testglue. This, for instance, is true about
testing ARC targets which uses its own DejaGnu board and
a simulator which does not support returning the pass or fail
through the exit code. Therefore, for those tests that use
"gdb_compile" a "gdb_tg.o" file is compiled and linked to the
final executable.
There are tests that invoke "gdb_compile" from different
directories. Let's take a look at an example test:
gdb.base/fullname.exp. The purpose of this test is to build
the executable from different directories (absolute vs. relative
vs. other) and then check if gdb can handle setting breakpoints
accordingly.
When "gdb_compile" generates the "gdb_tg.o", it does not
do it again for the same test. Although this might seem
efficient, it can lead to problems when changing directories
before the next compile:
gdb compile failed, arc-elf32-gcc: error: gdb_tg.o:
No such file or directory
This patch checks if the wrapper file ("gdb_tg.o") is still in
reach and if it is not, it will stimulate the generation of the
wrapper again.
It is worth mentioning that GCC's DejaGnu tests handle these
scenarios as well and they seem to be more efficient in doing so
by saving the library paths and manipulating them if necessary
[1]. However, for GDB tests, that require less compilations,
I think the proposed solution should be fine compared to a more
full fledged solution from GCC. The glue file in our case is
only 2 KiB.
Last but not least, I ran the x86_64 tests on an x86_64 host and
found no regression.
[1]
Avid coders may look for "set_ld_library_path_env_vars" in
gcc/testsuite/lib/target-libpath.exp.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_wrapper_init): Reset
"gdb_wrapper_initialized" to 0 if "wrapper_file" does
not exist.
---
gdb/testsuite/lib/gdb.exp | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index d5e22957039..8f55c4fcb2d 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -3565,6 +3565,15 @@ proc gdb_wrapper_init { args } {
global gdb_wrapper_flags
global gdb_wrapper_target
+ # if the wrapper is initialized but the wrapper file cannot be
+ # found anymore, the wrapper file must be built again.
+ if { $gdb_wrapper_initialized == 1 && \
+ [info exists gdb_wrapper_file] && \
+ ![file exists $gdb_wrapper_file] } {
+ verbose "reinitializing the wrapper"
+ set gdb_wrapper_initialized 0
+ }
+
if { $gdb_wrapper_initialized == 1 } { return; }
if {[target_info exists needs_status_wrapper] && \
@@ -3812,7 +3821,7 @@ proc gdb_compile {source dest type options} {
verbose "options are $options"
verbose "source is $source $dest $type $options"
- if { $gdb_wrapper_initialized == 0 } { gdb_wrapper_init }
+ gdb_wrapper_init
if {[target_info exists needs_status_wrapper] && \
[target_info needs_status_wrapper] != "0" && \
--
2.25.0