Re: [PATCH][PR gdb/8527] Interrupt not functional in Eclipse/CDT on Solaris

[Pedro Alves <palves@redhat.com>]

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 <http://www.gnu.org/licenses/>.  */
> +

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