From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27517 invoked by alias); 15 Aug 2014 05:00:30 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 27505 invoked by uid 89); 15 Aug 2014 05:00:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vc0-f172.google.com Received: from mail-vc0-f172.google.com (HELO mail-vc0-f172.google.com) (209.85.220.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 15 Aug 2014 05:00:27 +0000 Received: by mail-vc0-f172.google.com with SMTP id im17so2510662vcb.17 for ; Thu, 14 Aug 2014 22:00:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8J0lx0MXNHUlB7ASC9BNHaWP7MMBGiwd3DXN87JAmms=; b=VbABlzMo5KfRiXudSXjdtSnWRpdYyuHUev2w2ykx0gCeQroFG11W8GueiEckUR18xb hOP7N2Dygb5c5zjWCFV0TPqInY/9WZAJSR4w27UXXWLDQKIiSNisfzhj+oZeEFjYv3pg N4u5iox63k+W40bz6KPzE6fgUYBr0fdUcAWwHp2eKnlyHYKUZEH/UTKfn8sLPxemFMc3 86rewtukAXOloOUhITc/x8f3rkzbUuBbhankg7Gs5io2mMImYs7XDpv9480clg7rGd9Y GWjnNPBVY6DdkQLxSWlzFzWh+7lBHWKfQ/K03+h8Z/+mR+NbXZaIduRjWvsW2eK8a1jR 0NtA== X-Gm-Message-State: ALoCoQlBVR4bU0h7TLwa7LEOXTrUidhCtNeDZqE9uyvtIRgVdI6cQwJJr1ZT4MNKfhcsMlCJ2kEg MIME-Version: 1.0 X-Received: by 10.52.227.72 with SMTP id ry8mr39316vdc.64.1408078823473; Thu, 14 Aug 2014 22:00:23 -0700 (PDT) Received: by 10.52.136.203 with HTTP; Thu, 14 Aug 2014 22:00:23 -0700 (PDT) In-Reply-To: <1408075184-25947-1-git-send-email-yao@codesourcery.com> References: <1408075184-25947-1-git-send-email-yao@codesourcery.com> Date: Fri, 15 Aug 2014 05:00:00 -0000 Message-ID: Subject: Re: [PATCH 0/3] Keep track of files copied to host and target From: Doug Evans To: Yao Qi Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00269.txt.bz2 On Thu, Aug 14, 2014 at 8:59 PM, Yao Qi 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?