Copy .py files to remote host
Commit Message
Some gdb.python/*.exp tests fail because the .py files aren't copied
to the (remote) host. This patch is to copy needed .py files to host.
Most of gdb.python/*.exp tests do this.
gdb/testsuite:
2014-08-12 Yao Qi <yao@codesourcery.com>
* gdb.python/py-finish-breakpoint.exp: Copy .py file to host.
Delete the .py file on host when test is finished.
* gdb.python/py-finish-breakpoint2.exp: Likewise.
* gdb.python/python.exp: Likewise. Use .py file on the host
instead of the build.
---
gdb/testsuite/gdb.python/py-finish-breakpoint.exp | 15 ++++++++++++---
gdb/testsuite/gdb.python/py-finish-breakpoint2.exp | 6 +++++-
gdb/testsuite/gdb.python/python.exp | 13 +++++++++++--
3 files changed, 28 insertions(+), 6 deletions(-)
Comments
Yao Qi writes:
> Some gdb.python/*.exp tests fail because the .py files aren't copied
> to the (remote) host. This patch is to copy needed .py files to host.
> Most of gdb.python/*.exp tests do this.
>
> gdb/testsuite:
>
> 2014-08-12 Yao Qi <yao@codesourcery.com>
>
> * gdb.python/py-finish-breakpoint.exp: Copy .py file to host.
> Delete the .py file on host when test is finished.
> * gdb.python/py-finish-breakpoint2.exp: Likewise.
> * gdb.python/python.exp: Likewise. Use .py file on the host
> instead of the build.
> [...]
> ---
> gdb/testsuite/gdb.python/py-finish-breakpoint.exp | 15 ++++++++++++---
> gdb/testsuite/gdb.python/py-finish-breakpoint2.exp | 6 +++++-
> gdb/testsuite/gdb.python/python.exp | 13 +++++++++++--
> 3 files changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/gdb/testsuite/gdb.python/py-finish-breakpoint.exp b/gdb/testsuite/gdb.python/py-finish-breakpoint.exp
> index 43d0d81..45aa231 100644
> --- a/gdb/testsuite/gdb.python/py-finish-breakpoint.exp
> +++ b/gdb/testsuite/gdb.python/py-finish-breakpoint.exp
> @@ -53,9 +53,6 @@ if { $gdb_py_is_py24 == 1 } {
> return 0
> }
>
> -set python_file ${srcdir}/${subdir}/${testfile}.py
> -
> -
> # Skip all tests if Python scripting is not enabled.
> if { [skip_python_tests] } { continue }
>
> @@ -71,6 +68,9 @@ if ![runto_main] then {
> return 0
> }
>
> +set python_file [gdb_remote_download host \
> + ${srcdir}/${subdir}/${testfile}.py]
> +
> gdb_test_no_output "set confirm off" "disable confirmation"
> gdb_test "source $python_file" "Python script imported.*" \
> "import python scripts"
> @@ -115,6 +115,7 @@ gdb_test "source $python_file" "Python script imported.*" \
> set cond_line [gdb_get_line_number "Condition Break."]
>
> if ![runto_main] then {
> + remote_file host delete ${python_file}
> fail "Cannot run to main."
> return 0
> }
> @@ -141,6 +142,7 @@ gdb_test "source $python_file" "Python script imported.*" \
> "import python scripts"
>
> if ![runto call_longjmp_1] then {
> + remote_file host delete ${python_file}
> perror "couldn't run to breakpoint call_longjmp"
> continue
> }
> [...]
Hi.
I still have an outstanding question on this topic,
and before this gets checked in I'd like to get it resolved.
Do we delete other files downloaded to the remote target?
At one point I tried to find a place there the testsuite code was
taking care to delete other downloaded files, but couldn't.
Since we've gotten by this long without doing so
[and this is *still* just a hypothesis - I haven't worked with
remote hosts in awhile ...]
I would rather just punt on deleting python files as well,
and document that that is the convention (since for every other
file it already is :-)).
[Why treat python files differently?]
If we really did want to fully clean up after each test,
and we should first establish that that is indeed what we want to do,
instead of filling every test exit point with explicit code to delete
only one kind of downloaded file, how about instead keep a list of all
downloaded files and call a routine to delete the files in that list
from some central cleanup point?
On 8/12/14, 10:15 AM, Doug Evans wrote:
> Yao Qi writes:
> > Some gdb.python/*.exp tests fail because the .py files aren't copied
> > to the (remote) host. This patch is to copy needed .py files to host.
> > Most of gdb.python/*.exp tests do this.
> >
> > gdb/testsuite:
> >
> > 2014-08-12 Yao Qi <yao@codesourcery.com>
> >
> > * gdb.python/py-finish-breakpoint.exp: Copy .py file to host.
> > Delete the .py file on host when test is finished.
> > * gdb.python/py-finish-breakpoint2.exp: Likewise.
> > * gdb.python/python.exp: Likewise. Use .py file on the host
> > instead of the build.
> > [...]
> > ---
> > gdb/testsuite/gdb.python/py-finish-breakpoint.exp | 15 ++++++++++++---
> > gdb/testsuite/gdb.python/py-finish-breakpoint2.exp | 6 +++++-
> > gdb/testsuite/gdb.python/python.exp | 13 +++++++++++--
> > 3 files changed, 28 insertions(+), 6 deletions(-)
> >
> > diff --git a/gdb/testsuite/gdb.python/py-finish-breakpoint.exp b/gdb/testsuite/gdb.python/py-finish-breakpoint.exp
> > index 43d0d81..45aa231 100644
> > --- a/gdb/testsuite/gdb.python/py-finish-breakpoint.exp
> > +++ b/gdb/testsuite/gdb.python/py-finish-breakpoint.exp
> > @@ -53,9 +53,6 @@ if { $gdb_py_is_py24 == 1 } {
> > return 0
> > }
> >
> > -set python_file ${srcdir}/${subdir}/${testfile}.py
> > -
> > -
> > # Skip all tests if Python scripting is not enabled.
> > if { [skip_python_tests] } { continue }
> >
> > @@ -71,6 +68,9 @@ if ![runto_main] then {
> > return 0
> > }
> >
> > +set python_file [gdb_remote_download host \
> > + ${srcdir}/${subdir}/${testfile}.py]
> > +
> > gdb_test_no_output "set confirm off" "disable confirmation"
> > gdb_test "source $python_file" "Python script imported.*" \
> > "import python scripts"
> > @@ -115,6 +115,7 @@ gdb_test "source $python_file" "Python script imported.*" \
> > set cond_line [gdb_get_line_number "Condition Break."]
> >
> > if ![runto_main] then {
> > + remote_file host delete ${python_file}
> > fail "Cannot run to main."
> > return 0
> > }
> > @@ -141,6 +142,7 @@ gdb_test "source $python_file" "Python script imported.*" \
> > "import python scripts"
> >
> > if ![runto call_longjmp_1] then {
> > + remote_file host delete ${python_file}
> > perror "couldn't run to breakpoint call_longjmp"
> > continue
> > }
> > [...]
>
> Hi.
>
> I still have an outstanding question on this topic,
> and before this gets checked in I'd like to get it resolved.
> Do we delete other files downloaded to the remote target?
Going by instances of remote_file delete in the testsuite,
it's at least semi-standard to do so. It certainly reduces
the chances of confusion for any functionality that is based
on searching for a matching file to load/process.
> If we really did want to fully clean up after each test,
> and we should first establish that that is indeed what we want to do,
> instead of filling every test exit point with explicit code to delete
> only one kind of downloaded file, how about instead keep a list of all
> downloaded files and call a routine to delete the files in that list
> from some central cleanup point?
I could go for that. The existing deletions seem to be in a variety
of styles, and it would be useful to have standard failure handling
and such.
Stan
stan@codesourcery.com
On Tue, Aug 12, 2014 at 4:56 PM, Stan Shebs <stanshebs@earthlink.net> wrote:
> On 8/12/14, 10:15 AM, Doug Evans wrote:
>> [...]
>> I still have an outstanding question on this topic,
>> and before this gets checked in I'd like to get it resolved.
>> Do we delete other files downloaded to the remote target?
>
> Going by instances of remote_file delete in the testsuite,
> it's at least semi-standard to do so. It certainly reduces
> the chances of confusion for any functionality that is based
> on searching for a matching file to load/process.
It's a bit odd though to do this cleanup both in tcl and in "make clean".
I realize "make clean" won't remove remote files :-),
but there's still this weirdness of some files cleaned up by tcl
and some cleaned up by make.
It would be interesting to see some real data.
How hard would it be to start with a fresh build,
and do "ls -R" before/after a full testsuite run on a remote host.
IOW, what *are* the files that we're leaving behind on the remote host?
[I can do it, but I'm guessing someone already has a tree that is set up.]
>> If we really did want to fully clean up after each test,
>> and we should first establish that that is indeed what we want to do,
>> instead of filling every test exit point with explicit code to delete
>> only one kind of downloaded file, how about instead keep a list of all
>> downloaded files and call a routine to delete the files in that list
>> from some central cleanup point?
>
> I could go for that. The existing deletions seem to be in a variety
> of styles, and it would be useful to have standard failure handling
> and such.
Not only just having a standard, but saving having to remember
and fill every test exit point with special code.
On 08/13/2014 01:15 AM, Doug Evans wrote:
> I still have an outstanding question on this topic,
> and before this gets checked in I'd like to get it resolved.
> Do we delete other files downloaded to the remote target?
Yes, at least shared libs downloaded to target are cleaned up.
In lib/gdb.exp, there is a list cleanfiles, to record the files
downloaded to target, and in gdb_finish, remove files in this list.
>
> At one point I tried to find a place there the testsuite code was
> taking care to delete other downloaded files, but couldn't.
> Since we've gotten by this long without doing so
> [and this is *still* just a hypothesis - I haven't worked with
> remote hosts in awhile ...]
> I would rather just punt on deleting python files as well,
> and document that that is the convention (since for every other
> file it already is :-)).
> [Why treat python files differently?]
Where can we document this convention? gdb/testsuite/README? I can't
find a proper one. Existing test cases are good documentation to me,
and people usually follow the existing tests when they create new ones.
>
> If we really did want to fully clean up after each test,
> and we should first establish that that is indeed what we want to do,
> instead of filling every test exit point with explicit code to delete
> only one kind of downloaded file, how about instead keep a list of all
> downloaded files and call a routine to delete the files in that list
> from some central cleanup point?
Yeah, I also dislike writing "remote_file host delete $FOO" at the each
test exit point explicitly. Not sure what do you want in "fully clean
up", but at least, we can clean up python files as you said.
On Tue, Aug 12, 2014 at 5:52 PM, Yao Qi <yao@codesourcery.com> wrote:
> On 08/13/2014 01:15 AM, Doug Evans wrote:
>> I still have an outstanding question on this topic,
>> and before this gets checked in I'd like to get it resolved.
>> Do we delete other files downloaded to the remote target?
>
> Yes, at least shared libs downloaded to target are cleaned up.
> In lib/gdb.exp, there is a list cleanfiles, to record the files
> downloaded to target, and in gdb_finish, remove files in this list.
Yeah, we keep track of files downloaded to the target.
Can we do something similar for the host?
>>
>> At one point I tried to find a place there the testsuite code was
>> taking care to delete other downloaded files, but couldn't.
>> Since we've gotten by this long without doing so
>> [and this is *still* just a hypothesis - I haven't worked with
>> remote hosts in awhile ...]
>> I would rather just punt on deleting python files as well,
>> and document that that is the convention (since for every other
>> file it already is :-)).
>> [Why treat python files differently?]
>
> Where can we document this convention? gdb/testsuite/README? I can't
> find a proper one. Existing test cases are good documentation to me,
> and people usually follow the existing tests when they create new ones.
I think gdb/testsuite/README is fine.
>>
>> If we really did want to fully clean up after each test,
>> and we should first establish that that is indeed what we want to do,
>> instead of filling every test exit point with explicit code to delete
>> only one kind of downloaded file, how about instead keep a list of all
>> downloaded files and call a routine to delete the files in that list
>> from some central cleanup point?
>
> Yeah, I also dislike writing "remote_file host delete $FOO" at the each
> test exit point explicitly. Not sure what do you want in "fully clean
> up", but at least, we can clean up python files as you said.
If we keep track of files downloaded to the host like we do for the
target, it seems like this would be enough.
On Tue, Aug 12, 2014 at 8:09 PM, Doug Evans <dje@google.com> wrote:
> On Tue, Aug 12, 2014 at 5:52 PM, Yao Qi <yao@codesourcery.com> wrote:
>> On 08/13/2014 01:15 AM, Doug Evans wrote:
>>> I still have an outstanding question on this topic,
>>> and before this gets checked in I'd like to get it resolved.
>>> Do we delete other files downloaded to the remote target?
>>
>> Yes, at least shared libs downloaded to target are cleaned up.
>> In lib/gdb.exp, there is a list cleanfiles, to record the files
>> downloaded to target, and in gdb_finish, remove files in this list.
>
> Yeah, we keep track of files downloaded to the target.
> Can we do something similar for the host?
Though I should also say every time I've used a system that tries to
clean up after itself too much I generally grow to dislike it -
debugging failures gets harder because the files are gone.
If possible, I'd rather do a cleanup of the previous run beforehand
and just leave the results lying around afterwards (and often it's
easy because something simple like rm -rf $something is all that's
needed).
On Tue, Aug 12, 2014 at 10:50 PM, Doug Evans <dje@google.com> wrote:
> On Tue, Aug 12, 2014 at 8:09 PM, Doug Evans <dje@google.com> wrote:
>> On Tue, Aug 12, 2014 at 5:52 PM, Yao Qi <yao@codesourcery.com> wrote:
>>> On 08/13/2014 01:15 AM, Doug Evans wrote:
>>>> I still have an outstanding question on this topic,
>>>> and before this gets checked in I'd like to get it resolved.
>>>> Do we delete other files downloaded to the remote target?
Oops, I meant remote host here.
Bleah, sorry about that.
>>> Yes, at least shared libs downloaded to target are cleaned up.
>>> In lib/gdb.exp, there is a list cleanfiles, to record the files
>>> downloaded to target, and in gdb_finish, remove files in this list.
>>
>> Yeah, we keep track of files downloaded to the target.
>> Can we do something similar for the host?
>
> Though I should also say every time I've used a system that tries to
> clean up after itself too much I generally grow to dislike it -
> debugging failures gets harder because the files are gone.
> If possible, I'd rather do a cleanup of the previous run beforehand
> and just leave the results lying around afterwards (and often it's
> easy because something simple like rm -rf $something is all that's
> needed).
On Tue, Aug 12, 2014 at 4:56 PM, Stan Shebs <stanshebs@earthlink.net> wrote:
> On 8/12/14, 10:15 AM, Doug Evans wrote:
>> [...]
>> I still have an outstanding question on this topic,
>> and before this gets checked in I'd like to get it resolved.
>> Do we delete other files downloaded to the remote target?
[For clarity's sake: I meant to say "remote host" here, not "remote target".]
> Going by instances of remote_file delete in the testsuite,
> it's at least semi-standard to do so. It certainly reduces
> the chances of confusion for any functionality that is based
> on searching for a matching file to load/process.
To collect some data, I ran an experiment to see what kinds of files
were left on the remote host.
I didn't use boards/local-remote-host*, I wanted to get something
closer to real remote host testing and remove any possible confusion
on my part.
It took a bit and in the end I made a simple albeit ugly hack to my
.bashrc since I just wanted to collect some data.
I see source files, object files, binaries left on the remote host.
That's what I expected, and that's what led me to say:
>>Since we've gotten by this long without doing so
>>[and this is *still* just a hypothesis - I haven't worked with
>>remote hosts in awhile ...]
>>I would rather just punt on deleting python files as well,
>>and document that that is the convention (since for every other
>>file it already is :-)).
I think my claim that that is already the convention for every other
file is at least not totally invalid. :-)
Maybe effort went into cleaning up remote target files because they
can have vastly smaller file systems.
btw, t would be good to have another version of local-remote-host*
that more closely mapped real remote host testing to improve coverage,
assuming remote host testing is still done by someone these days
(possible alright).
@@ -53,9 +53,6 @@ if { $gdb_py_is_py24 == 1 } {
return 0
}
-set python_file ${srcdir}/${subdir}/${testfile}.py
-
-
# Skip all tests if Python scripting is not enabled.
if { [skip_python_tests] } { continue }
@@ -71,6 +68,9 @@ if ![runto_main] then {
return 0
}
+set python_file [gdb_remote_download host \
+ ${srcdir}/${subdir}/${testfile}.py]
+
gdb_test_no_output "set confirm off" "disable confirmation"
gdb_test "source $python_file" "Python script imported.*" \
"import python scripts"
@@ -115,6 +115,7 @@ gdb_test "source $python_file" "Python script imported.*" \
set cond_line [gdb_get_line_number "Condition Break."]
if ![runto_main] then {
+ remote_file host delete ${python_file}
fail "Cannot run to main."
return 0
}
@@ -141,6 +142,7 @@ gdb_test "source $python_file" "Python script imported.*" \
"import python scripts"
if ![runto call_longjmp_1] then {
+ remote_file host delete ${python_file}
perror "couldn't run to breakpoint call_longjmp"
continue
}
@@ -168,6 +170,7 @@ gdb_test "source $python_file" "Python script imported.*" \
if ![runto_main] then {
+ remote_file host delete ${python_file}
fail "Cannot run to main."
return 0
}
@@ -193,6 +196,7 @@ gdb_test "source $python_file" "Python script imported.*" \
"import python scripts"
if ![runto_main] then {
+ remote_file host delete ${python_file}
fail "Cannot run to main."
return 0
}
@@ -220,6 +224,7 @@ gdb_test "source $python_file" "Python script imported.*" \
"import python scripts"
if ![runto_main] then {
+ remote_file host delete ${python_file}
fail "Cannot run to main."
return 0
}
@@ -247,6 +252,7 @@ gdb_test "print increase(&i)" \
#
if ![runto "test_exec_exit"] then {
+ remote_file host delete ${python_file}
fail "Cannot run to test_exec_exit."
return 0
}
@@ -260,6 +266,7 @@ gdb_test "continue" "SimpleFinishBreakpoint out of scope.*" "catch out of scope
#
if ![runto "test_exec_exit"] then {
+ remote_file host delete ${python_file}
fail "Cannot run to test_exec_exit."
return 0
}
@@ -267,3 +274,5 @@ if ![runto "test_exec_exit"] then {
gdb_test "python SimpleFinishBreakpoint(gdb.newest_frame())" "SimpleFinishBreakpoint init" "set FinishBP after the exec"
gdb_test "catch exec" "Catchpoint.*\(exec\).*" "catch exec"
gdb_test "continue" "SimpleFinishBreakpoint out of scope.*" "catch out of scope after exec"
+
+remote_file host delete ${python_file}
@@ -19,7 +19,6 @@
load_lib gdb-python.exp
standard_testfile .cc
-set pyfile ${srcdir}/${subdir}/${testfile}.py
if {[prepare_for_testing $testfile.exp $testfile $srcfile {debug c++}]} {
return -1
@@ -33,6 +32,9 @@ if ![runto_main] then {
return 0
}
+set pyfile [gdb_remote_download host \
+ ${srcdir}/${subdir}/${testfile}.py]
+
#
# Check FinishBreakpoints against C++ exceptions
#
@@ -53,3 +55,5 @@ gdb_test "python print (len(gdb.breakpoints()))" "3" "check finish BP removal"
gdb_test "continue" ".*Breakpoint.* throw_exception_1.*" "continue to second exception"
gdb_test "python ExceptionFinishBreakpoint(gdb.newest_frame())" "init ExceptionFinishBreakpoint" "set FinishBP after the exception"
gdb_test "continue" ".*exception did not finish.*" "FinishBreakpoint with exception thrown not caught"
+
+remote_file host delete ${pyfile}
@@ -30,6 +30,9 @@ gdb_exit
gdb_start
gdb_reinitialize_dir $srcdir/$subdir
+set remote_source2_py [gdb_remote_download host \
+ ${srcdir}/${subdir}/source2.py]
+
# Do this instead of the skip_python_check.
# We want to do some tests when Python is not present.
gdb_test_multiple "python print (23)" "verify python support" {
@@ -38,7 +41,7 @@ gdb_test_multiple "python print (23)" "verify python support" {
# If Python is not supported, verify that sourcing a python script
# causes an error.
- gdb_test "source $srcdir/$subdir/source2.py" \
+ gdb_test "source $remote_source2_py" \
"Error in sourced command file:.*" \
"source source2.py when python disabled"
@@ -48,6 +51,7 @@ gdb_test_multiple "python print (23)" "verify python support" {
"print (23)" "" \
"end" "not supported.*"
+ remote_file host delete ${remote_source2_py}
return -1
}
-re "$gdb_prompt $" {}
@@ -73,7 +77,7 @@ gdb_py_test_multiple "indented multi-line python command" \
"foo ()" "" \
"end" "hello, world!"
-gdb_test "source $srcdir/$subdir/source2.py" "yes" "source source2.py"
+gdb_test "source $remote_source2_py" "yes" "source source2.py"
gdb_test "source -s source2.py" "yes" "source -s source2.py"
@@ -171,6 +175,7 @@ clean_restart ${testfile}
# The following tests require execution.
if ![runto_main] then {
+ remote_file host delete ${remote_source2_py}
fail "Can't run to main"
return 0
}
@@ -333,6 +338,7 @@ clean_restart ${testfile}
# The following tests require execution.
if ![runto_main] then {
+ remote_file host delete ${remote_source2_py}
fail "Can't run to main"
return 0
}
@@ -389,6 +395,7 @@ clean_restart ${testfile}
# The following tests require execution.
if ![runto_main] then {
+ remote_file host delete ${remote_source2_py}
fail "Can't run to main"
return 0
}
@@ -402,3 +409,5 @@ gdb_py_test_silent_cmd "step" "Step into func2" 1
gdb_py_test_silent_cmd "up" "Step out of func2" 1
gdb_test "python print (gdb.find_pc_line(gdb.selected_frame().pc()).line > line)" "True" "Test find_pc_line with resume address"
+
+remote_file host delete ${remote_source2_py}