[PATCH][gdb/testsuite] Fix gdb.threads/killed-outside.exp with -m32

[Pedro Alves]

On 13/04/21 16:51, Luis Machado wrote:
> On 4/13/21 11:45 AM, Pedro Alves wrote:
>> On 13/04/21 14:33, Luis Machado wrote:
>>>
>>> Forcing scheduler-locking to on made the output consistent for both cases, but I was left wondering if enabling scheduler-locking would cause the bug to not be reproducible anymore.
>>
>> Yeah, no.  That would just paper over problems.  GDB should cope with threads disappearing beneath it, as they're resumed, stopped, etc.  Forcing scheduler-locking just
>> means you're only resuming one thread instead of many, and thus reducing the chances of some GDB issue triggering.  Wouldn't be much different from making the testcase
>> be single-threaded.
> 
> Right. The non-deterministic nature of the output makes it harder to find a reliable pattern to match.
> 
> There seems to be a couple issues at play here. One is the non-deterministic ordering of thread-related outputs, which is expected and we can't do much about it. Though I'd expect a thread exit notification to always show up, and not be swallowed by GDB.
> 
> The other is the non-deterministic position of the gdb prompt, even for all-stop mode. Sometimes it shows up before GDB gets a chance to output other messages, like so:
> 
> Executing on target: kill -9 3742839    (timeout = 300)
> spawn -ignore SIGHUP kill -9 3742839^M
> continue^M
> Continuing.^M
> Unable to fetch general registers.: No such process.^M
> (gdb) [Thread 0xfffff7e281e0 (LWP 3742842) exited]^M
> ^M
> Program terminated with signal SIGKILL, Killed.^M
> The program no longer exists.^M
> FAIL: gdb.threads/killed-outside.exp: prompt after first continue (timeout)
> 

That's a GDB bug.  GDB shouldn't have given the prompt so soon.  I think it did because
the "No such process" error escapes out.