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

["Rainer Orth" <ro at CeBiTec dot Uni-Bielefeld dot DE>]

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