This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 3/3] Add test for fetching TLS from core file
- From: Simon Marchi <simon dot marchi at polymtl dot ca>
- To: "Maciej W. Rozycki" <macro at mips dot com>
- Cc: Djordje Todorovic <djordje dot todorovic at rt-rk dot com>, Pedro Alves <palves at redhat dot com>, binutils at sourceware dot org, gdb-patches at sourceware dot org, asowda at cisco dot com, petar dot jovanovic at rt-rk dot com, nemanja dot popov at rt-rk dot com, nikola dot prica at rt-rk dot com
- Date: Mon, 23 Oct 2017 21:56:19 -0400
- Subject: Re: [PATCH 3/3] Add test for fetching TLS from core file
- Authentication-results: sourceware.org; auth=none
- References: <cfd1fbbf3af8ec0430da8b91a1a68e98@polymtl.ca> <alpine.DEB.2.00.1710192123531.3886@tp.orcam.me.uk>
On 2017-10-23 19:42, Maciej W. Rozycki wrote:
You can't guarantee overall a test program won't hang, loop, etc. due
to
a bug somewhere. The issue of lingering processes should IMHO be
handled
by assigning software run on the target a new session and then killing
the
process group on completion. I believe this is actually done already,
as
this is how expect's `spawn' works and I think we also have it handled
for
the remote case in the `gdbserver' test harness (but I'd love to get a
confirmation here).
How do you propose anyway, in the absence of an infinite wait/loop, to
ensure that the process does not terminate before the test harness has
done its processing?
Ah sorry, I saw the while (1) loop in the thread function, and thought
that the main function waited for the threads to complete. But it
doesn't, it would exit right away after creating the threads.
What I meant was to try to avoid infinite loops. Instead of
while (1)
sleep (1);
you can generally do
for (int i = 0; i < 100; i++)
sleep (1);
So that if the process runs free, it will eventually exit by itself.
Simon