From: Doug Evans <dje@google.com>
To: Yao Qi <yao@codesourcery.com>
Cc: gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH 0/3] Keep track of files copied to host and target
Date: Fri, 15 Aug 2014 05:00:00 -0000 [thread overview]
Message-ID: <CADPb22R3YtLfqtFWCC6-CfV1gr1fd1nj9-j=J4T-ELR9VrCtEQ@mail.gmail.com> (raw)
In-Reply-To: <1408075184-25947-1-git-send-email-yao@codesourcery.com>
On Thu, Aug 14, 2014 at 8:59 PM, Yao Qi <yao@codesourcery.com> wrote:
> In current GDB testsuite, .py files (in gdb.python), file1.txt (in
> gdb.dwarf2), and .xml files (in gdb.xml) are copied to host at
> the beginning of the tests, and removed at the end of the test.
> However, GDB testsuite also copies files to target, but automatically
> track them in gdb.exp:cleanfiles, and remove them from target when
> each test is finished.
>
> This patch series is teach GDB testsuite to keep track of files copied
> to host and remove them when test is finished, the same as what we
> did for files copied to target. The files copied to both target and
> host are tracked in an unified way.
>
> Patch #1 is to extend existing cleanfiles for not only target but also
> host. In patch #2, we start to keep track of files copied to host in
> cleanfiles, so that each test doesn't have to remove them at the end.
> Patch #3 is to copy some needed .py files to host, to fix some fails
> in remote host testing.
>
> The patch series is tested in native and gdbserver on x86_64-linux.
> I also test it with my local board file to emulate gdb native testing
> in a remote host (host == target != build), result looks good. I'll
> tweak it a little and post it shortly. I also find some tests don't
> copy needed file to host, and I'll fix them separately.
Hi.
I hate to be a naysayer here, but I'm not convinced we should go down this path.
For one, I like files being left over after a test run.
I would certainly object to cleaning up test binaries in native runs
(at least without providing an easy way to not do that). I run "make
check" and then manually play with the created binary *all the time*.
I'm quite sure I'd feel the same way if I were doing Canadian Cross
testing, or at least remote host testing.
For another, I'd like to see a patch that cleans up all the other
files (e.g., source files, object files, binaries) that dejagnu
downloads as part of building the testcases. I could be missing
something, this is based on my experiments and maybe I missed
something. In my experiment, after "make check" had finished (at least
I think it finished) there were ~1000 files in ~30MB left on the
remote host. If the test didn't finish it may have been because I'd
shutdown my machine too soon. :-) At any rate, it feels like what this
patch set will clean up is a drop in the bucket compared to that.
If we're not going to clean those up, I'd rather not complicate things
further but only solving part of the problem (and a relatively far
smaller part of the problem too).
Can we solve this problem differently perhaps?
Is this just an appeal to some view of cleanliness, or is there a
practical problem (running out of disk space or some such?) that the
patch set is intended to solve?
next prev parent reply other threads:[~2014-08-15 5:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-15 4:04 Yao Qi
2014-08-15 4:04 ` [PATCH 3/3] Copy .py files to remote host Yao Qi
2014-08-15 4:04 ` [PATCH 1/3] Extend cleanfiles for multiple hosts Yao Qi
2014-08-15 4:04 ` [PATCH 2/3] Keep track of downloaded file in gdb_remote_download Yao Qi
2014-08-15 5:00 ` Doug Evans [this message]
2014-08-15 6:08 ` [PATCH 0/3] Keep track of files copied to host and target Yao Qi
2014-08-16 0:38 ` Doug Evans
2014-08-20 6:54 ` Yao Qi
2014-08-20 15:17 ` Pedro Alves
2014-08-20 15:48 ` Doug Evans
2014-08-21 0:35 ` Yao Qi
2014-08-21 17:32 ` Doug Evans
2014-08-22 6:14 ` Yao Qi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CADPb22R3YtLfqtFWCC6-CfV1gr1fd1nj9-j=J4T-ELR9VrCtEQ@mail.gmail.com' \
--to=dje@google.com \
--cc=gdb-patches@sourceware.org \
--cc=yao@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox