From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100289 invoked by alias); 26 Feb 2019 16:09:06 -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 100273 invoked by uid 89); 26 Feb 2019 16:09:06 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=BAYES_00,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=fundamentally X-HELO: mail-wm1-f45.google.com Received: from mail-wm1-f45.google.com (HELO mail-wm1-f45.google.com) (209.85.128.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Feb 2019 16:09:04 +0000 Received: by mail-wm1-f45.google.com with SMTP id o10so2469770wmc.1 for ; Tue, 26 Feb 2019 08:09:04 -0800 (PST) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:75e6:857f:3506:a1f4? ([2001:8a0:f913:f700:75e6:857f:3506:a1f4]) by smtp.gmail.com with ESMTPSA id t69sm9285234wmt.16.2019.02.26.08.09.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Feb 2019 08:09:01 -0800 (PST) Subject: Re: [PATCH][PR gdb/8527] Interrupt not functional in Eclipse/CDT on Solaris To: Rainer Orth , Joel Brobecker References: <20181101211949.GB2705@adacore.com> Cc: Brian Vandenberg , gdb-patches@sourceware.org From: Pedro Alves Message-ID: <318b122f-29b1-27fa-7693-497c0c185410@redhat.com> Date: Tue, 26 Feb 2019 16:09:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-02/txt/msg00436.txt.bz2 Hi Rainer, On 02/26/2019 03:14 PM, Rainer Orth wrote: >> Looking for possible testcases to modify, I first came >> gdb.base/interrupt-daemon.exp. However, there turned out to be two >> issues: I'd needed the pid of the grandchild process to attach to, and >> this wasn't emitted to gdb.log when printed. >> >> Besides, when I checked the test as is, it already FAILs on Solaris. >> This seems to happen because set follow-fork-mode child isn't >> implemented, but fails silently and the list of targets supporting it is >> is either incomplete or completely missing in the tests that use it. It's a shame that the Solaris port doesn't support follow-fork. I don't suppose there's anything fundamentally impossible. I'm sure it must be possible to intercept fork/vfork/exec events with procfs. >> However, when I tested the testcase on Linux/x86_64, it FAILs: >> >> attach 113292 >> Attaching to program: >> /vol/gcc/obj/gdb/gdb/dist/gdb/testsuite/outputs/gdb.base/signal-no-ctty/signal-no-ctty, >> process 113292 >> warning: process 113292 is a zombie - the process has already terminated >> ptrace: Operation not permitted. >> (gdb) FAIL: gdb.base/signal-no-ctty.exp: attach: attach >> >> The weird thing is that both with the setpgrp call and when run like >> >> $ ./signal-no-ctty < /dev/null >& /dev/null & >> >> ps still shows a controlling terminal for the process. Don't yet know >> what's going on here. >> >> Current patch attached for reference. > I never got a reply to this one, but I think I just figured out the > testcase part myself. I'm curious -- what was the issue on Linux? > +++ b/gdb/testsuite/gdb.base/sigint-no-ctty.exp > @@ -0,0 +1,87 @@ > +# Copyright 2019 Free Software Foundation, Inc. > + > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation; either version 3 of the License, or > +# (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program. If not, see . */ > + Please add a small intro comment mentioning what the testcase is about. AFAICT, this is basically testing the same thing that gdb.base/interrupt-daemon.exp is testing, with the difference that it exercises inferiors started with "attach" instead of "run". I'd suggest renaming the testcase to interrupt-daemon-attach.exp, so that it sits alongside interrupt-daemon.exp. > +if [target_info exists gdb,nosignals] { > + verbose "Skipping signal-no-ctty.exp because of nosignals." > + continue > +} > + > +# This test requires sending ^C to interrupt the running target. > +if [target_info exists gdb,nointerrupts] { > + verbose "Skipping signal-no-ctty.exp because of nointerrupts." > + return > +} > + > +standard_testfile > + > +if { [build_executable ${testfile}.exp ${testfile} $srcfile {debug}] == -1 } { > + return -1 > +} > + > +proc do_test {} { > + global binfile > + global decimal > + > + set test_spawn_id [spawn_wait_for_attach $binfile] This is missing a can_wait_for_attach check: $ make check TESTS="gdb.base/sigint-no-ctty.exp" RUNTESTFLAGS="--target_board=native-gdbserver" ... ERROR: tcl error sourcing src/gdb/testsuite/gdb.base/sigint-no-ctty.exp. ERROR: can't spawn for attach with this target/board while executing "error "can't spawn for attach with this target/board"" invoked from within "if ![can_spawn_for_attach] { # The caller should have checked can_spawn_for_attach itself # before getting here. error "can't spawn for attach with..." (procedure "spawn_wait_for_attach" line 4) invoked from within Otherwise, this is fine with me. Thanks, Pedro Alves