From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112222 invoked by alias); 30 Jun 2016 12:10:50 -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 112082 invoked by uid 89); 30 Jun 2016 12:10:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=sx, 2346, Process X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 30 Jun 2016 12:10:46 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5A99D7F6A6; Thu, 30 Jun 2016 12:10:45 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5UCAhuu011507; Thu, 30 Jun 2016 08:10:44 -0400 Subject: gdbserver/ada testing broken (was: Re: [pushed] Fix gdbserver/MI testing regression) To: Simon Marchi References: <1462538104-19109-1-git-send-email-palves@redhat.com> <1462538104-19109-32-git-send-email-palves@redhat.com> <5772DBCA.4090802@ericsson.com> <813555f3-c917-cd95-6d41-3ec64cad2cf6@redhat.com> <14e113dd-0488-79d0-6cde-82cdb1562793@redhat.com> From: Pedro Alves Cc: gdb-patches@sourceware.org, Joel Brobecker Message-ID: Date: Thu, 30 Jun 2016 12:10:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <14e113dd-0488-79d0-6cde-82cdb1562793@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-06/txt/msg00534.txt.bz2 BTW, while testing this, I noticed that all gdb.ada/ tests that build a binary with the same name as their test directory are broken. I suspect this is a regression caused by one of the gdb_remote_download, etc. patches. For example: Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/formatted_ref.exp ... PASS: gdb.ada/formatted_ref.exp: compilation formatted_ref.adb FAIL: gdb.ada/formatted_ref.exp: print/x s FAIL: gdb.ada/formatted_ref.exp: print/x s'access FAIL: gdb.ada/formatted_ref.exp: print s.x = 13 gdb.log shows: The program is not being run. (gdb) file /home/pedro/brno/pedro/gdb/mygit/build/gdb/testsuite/outputs/gdb.ada/formatted_ref/formatted_ref/formatted_ref Reading symbols from /home/pedro/brno/pedro/gdb/mygit/build/gdb/testsuite/outputs/gdb.ada/formatted_ref/formatted_ref/formatted_ref...done. ... (gdb) spawn ../gdbserver/gdbserver --once :2346 /home/pedro/brno/pedro/gdb/mygit/build/gdb/testsuite/outputs/gdb.ada/formatted_ref/formatted_ref Process /home/pedro/brno/pedro/gdb/mygit/build/gdb/testsuite/outputs/gdb.ada/formatted_ref/formatted_ref created; pid = 7553 Cannot exec /home/pedro/brno/pedro/gdb/mygit/build/gdb/testsuite/outputs/gdb.ada/formatted_ref/formatted_ref: Permission denied. Child exited with status 127 No program to debug Note how gdb loads: .../gdb.ada/formatted_ref/formatted_ref/formatted_ref while gdbserver tries to load: .../gdb.ada/formatted_ref/formatted_ref ... which fails because it's the directory. This is probably because gdb_remote_download only minds "tail" when deciding the destination filename: proc gdb_remote_download {dest fromfile {tofile {}}} { # If TOFILE is not given, default to the same filename as FROMFILE. if {[string length $tofile] == 0} { set tofile [file tail $fromfile] } if {[is_remote $dest]} { # When the DEST is remote, we simply send the file to DEST. global cleanfiles set destname [remote_download $dest $fromfile $tofile] lappend cleanfiles $destname return $destname and then gdbserver-base.exp does: proc ${board}_download { board host dest } { # We pass DEST in standard_output_file, regardless of whether it is absolute # or relative, because we don't want the tests to be able to write outside # their standard output directory. set dest [standard_output_file $dest] file copy -force $host $dest return $dest } Here $dest already exists when we get here -- it's the directory. I haven't confirmed, just inspected the code. Not sure exactly what the best fix is. Maybe simply tweak the tests to never get into this situation, along with making standard_ada_testfile issue perror when it happens? Most tests pass an explicit base_file name to standard_ada_testfile that avoids the conflict, like: gdb.ada/str_ref_cmp.exp:18:standard_ada_testfile foo Maybe standard_ada_testfile's $base_file parameter should be defaulted, like: -proc standard_ada_testfile {base_file {dir ""}} { +proc standard_ada_testfile {{base_file "test"} {dir ""}} { and then most tests adjusted to not pass an explicit base_file at all. Thanks, Pedro Alves