[PATCH][PR gdb/8527] Interrupt not functional in Eclipse/CDT on Solaris
Pedro Alves
palves@redhat.com
Tue Feb 26 16:09:00 GMT 2019
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
More information about the Gdb-patches
mailing list