From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84777 invoked by alias); 6 May 2015 16:12:22 -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 84768 invoked by uid 89); 6 May 2015 16:12:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 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; Wed, 06 May 2015 16:12:20 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 87D6E96C4; Wed, 6 May 2015 16:12:19 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t46GCHNJ011712; Wed, 6 May 2015 12:12:18 -0400 Message-ID: <554A3D61.8090302@redhat.com> Date: Wed, 06 May 2015 16:12:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Yao Qi , gdb-patches@sourceware.org Subject: Re: [rfc] Fix PR 18208: update /proc/pid/coredump_filter by c code References: <1429889336-12277-1-git-send-email-qiyaoltc@gmail.com> In-Reply-To: <1429889336-12277-1-git-send-email-qiyaoltc@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-05/txt/msg00112.txt.bz2 On 04/24/2015 04:28 PM, Yao Qi wrote: > We see some fails in gdb.base/coredump-filter.exp when we do remote > gdbserver testing, like what I did for arm/aarch64 linux testing or > run it with board file remote-gdbserver-on-localhost > > $ make check RUNTESTFLAGS='--target_board=remote-gdbserver-on-localhost coredump-filter.exp' > > we find that this line in the test doesn't work as expected, > > remote_exec target "sh -c \"echo $filter_flag > /proc/$ipid/coredump_filter\"" > > although such pattern has been used in gdb testsuite somewhere else, > but the special thing here is that we redirect the output to > /proc/$ipid/coredump_filter on the remote target. DejaGNU will > redirect the output from the remote target to local, and looks tcl > gets confused by these two redirection. Not sure what exactly gets confused either. > > After trying pass different parameters to remote_exec and hacking > remote_exec/rsh_exec/local_exec, I got no success, I decide > to give up, and try to update /proc/$ipid/coredump_filter by the c > code directly. Probably the right fix would be for dejagnu to put ''s around the whole sh -c command in rsh_exec: set ret [local_exec "$RSH $rsh_useropts $hostname sh -c '$program $pargs \\; echo XYZ\\\${?}ZYX'" $inp $outp $timeout] dunno if that would work with real rsh. Alternatively, teach dejagnu about a real ssh mode... > > This patch adds a c function set_coredump_filter to update > coredump_filter, and GDB calls it. > This is fine with me. > Now this test passes on boardfile unix, native-gdbserver and > remote-gdbserver-on-localhost. It also passes my board files for arm > and aarch64 testing. > # Generate a corefile. > gdb_gcore_cmd "$core" "save corefile" > @@ -146,11 +146,8 @@ if { !$core_supported } { > return -1 > } > > -# Get the inferior's PID. > -set infpid "" > gdb_test_multiple "info inferiors" "getting inferior pid" { > - -re "process \($decimal\).*\r\n$gdb_prompt $" { > - set infpid $expect_out(1,string) > + -re "process $decimal.*\r\n$gdb_prompt $" { > } > -re "Remote target.*$gdb_prompt $" { > # If the target does not provide PID information (like usermode QEMU), This "If the target does not provide PID information" check sounds odd now. Do we still need it? Thanks, Pedro Alves