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

[Luis Machado]

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)

I was considering the possibility of adjusting the test, but I may be 
dealing with other GDB bugs.