From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6123 invoked by alias); 28 Feb 2019 15:16:29 -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 6103 invoked by uid 89); 28 Feb 2019 15:16:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.2 required=5.0 tests=BAYES_50,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY autolearn=ham version=3.3.2 spammy=Hx-languages-length:4388, dist, sourcing, sits X-HELO: smtp.CeBiTec.Uni-Bielefeld.DE Received: from smtp.CeBiTec.Uni-Bielefeld.DE (HELO smtp.CeBiTec.Uni-Bielefeld.DE) (129.70.160.84) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 28 Feb 2019 15:16:27 +0000 Received: from localhost (localhost.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 47E0EBE0; Thu, 28 Feb 2019 16:16:25 +0100 (CET) Received: from smtp.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (malfoy.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tPK0FHn0-1JO; Thu, 28 Feb 2019 16:16:21 +0100 (CET) Received: from piggy (piggy.CeBiTec.Uni-Bielefeld.DE [129.70.160.213]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with SMTP id 9FD4ABDF; Thu, 28 Feb 2019 16:16:20 +0100 (CET) Received: by piggy (sSMTP sendmail emulation); Thu, 28 Feb 2019 16:16:20 +0100 From: "Rainer Orth" To: Pedro Alves Cc: Joel Brobecker , Brian Vandenberg , gdb-patches@sourceware.org Subject: Re: [PATCH][PR gdb/8527] Interrupt not functional in Eclipse/CDT on Solaris References: <20181101211949.GB2705@adacore.com> <318b122f-29b1-27fa-7693-497c0c185410@redhat.com> Date: Thu, 28 Feb 2019 15:16:00 -0000 In-Reply-To: (Rainer Orth's message of "Tue, 26 Feb 2019 21:03:41 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00565.txt.bz2 Hi Pedro, >> 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. > > certainly: that's just one of many warts of the port. However, before > looking into adding missing features, I need to spend some time > investigating the large number of tests that fail (often timeouts) that > make the testsuite impossible to run usefully in the buildbots, taking > at least half an hour to complete and being flaky as hell in some areas. > >>>> 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? > > The initial testcase was just misguided: I found no reliable way to > really detach from the controlling tty without fork (which I'd have > liked to avoid in order not to have to jump through hoops to determine > the child pid). I haven't looked closer after several false attempts to > make this work, but just started afresh from attach-non-pgrp-leader.exp > instead and modified that. > >>> +++ b/gdb/testsuite/gdb.base/sigint-no-ctty.exp > [...] >> Please add a small intro comment mentioning what the testcase is about. > > Done now. > >> 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 > > More or less so, yes. Just without the double fork and the bg variant > that isn't supported on Solaris. > >> renaming the testcase to interrupt-daemon-attach.exp, so that it sits >> alongside interrupt-daemon.exp. > > Fine with me. > >>> +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 > > Fixed now: didn't happen for me since I'm only testing on Unix targets. > >> Otherwise, this is fine with me. > > Here's the revised version, successfully tested as before. Ok for > master now? I've commited the patch to master now, taking the above as approval. Also ok for the 8.3 branch after a couple of days once it's clear the testcase works everywhere? Thanks. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University