This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] remote-sim add call to init_thread_list
- From: Pedro Alves <palves at redhat dot com>
- To: Andrew Burgess <aburgess at broadcom dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Thu, 11 Oct 2012 15:31:28 +0100
- Subject: Re: [PATCH] remote-sim add call to init_thread_list
- References: <506C2A17.8060000@broadcom.com>
On 10/03/2012 01:05 PM, Andrew Burgess wrote:
> When running using a basic exec style target (on linux) I see the following behaviour:
>
>> gdb ./test-program
> (gdb) start
> (gdb) info threads
> Id Target Id Frame
> * 1 process 12285 main () at hello.c:5
> (gdb) start
> The program being debugged has been started already.
> Start it from the beginning? (y or n) y
>
> (gdb) info threads
> Id Target Id Frame
> * 1 process 16295 main () at hello.c:5
>
> ## END ##
>
> Notice that the thread ID remains as 1 after the restart. This is due to the call to init_thread_list in gdb/fork-child.c:fork_inferior.
>
> Currently, when using a simulator target, the ID will increment on each restart.
>
> The patch below adds a similar call to init_thread_list to remote-sim.c:create_inferior so the simulator behaviour will match the native exec style target behaviour.
>
> OK to apply?
OK.
I'll note that even native GNU/Linux isn't consistent -- e.g., "normal exit" followed
by "attach"; or just "attach" without killing the previous inferior incarnation (and then
answering yes to the "are you sure you want to kill/detach/whatnot" question) results
in the ID being incremented. Looks like a general audit of target behavior, and moving
things to common code when appropriate would be good.
--
Pedro Alves