This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] improved thread id reporting
- From: Doug Evans <dje at google dot com>
- To: gdb-patches <gdb-patches at sourceware dot org>
- Date: Mon, 18 May 2009 16:23:15 -0700
- Subject: Re: [RFA] improved thread id reporting
- References: <20090404184604.8524C1C759C@localhost> <200904041904.n34J4UXV013513@brahms.sibelius.xs4all.nl> <20090404192132.GA28232@caradoc.them.org> <e394668d0904051336p56704603of8c9c31742dc04e6@mail.gmail.com> <20090406033300.GA31715@caradoc.them.org> <e394668d0905072243y22eee593u94d753edf0f807f0@mail.gmail.com> <e394668d0905072246l2e665772k41bb136a23c59af@mail.gmail.com>
Ping.
Ok to check in?
On Thu, May 7, 2009 at 10:46 PM, Doug Evans <dje@google.com> wrote:
> Blech. ?Right list this time.
>
>
> On Sun, Apr 5, 2009 at 8:33 PM, Daniel Jacobowitz <drow@false.org> wrote:
>> On Sun, Apr 05, 2009 at 01:36:06PM -0700, Doug Evans wrote:
>>> Attached is a simplistic patch to help illustrate the challenge.
>>>
>>> Here is an example session that prints from/to and the thread number
>>> in "[New ...", "[Switching ...", etc. messages.
>>> I can think of two issues with the patch:
>>> 1) Printing "[tT]hread" twice in one line is a bit annoying.
>>> 2) Spreading from/to over two lines is a bit annoying.
>>
>> What do you think of this? ?On the theory that you can go look up
>> thread #2, either in 'info threads' or in a previous notification:
>>
>> [Switching from thread #2 to thread #3, Thread 0x41001960 (LWP 14407)]
>
> "works for me"
>
>> Or, migrating the "Thread" out:
>>
>> [Switching from thread #2 to thread #3, 0x41001960 (LWP 14407)]
>>
>> But that might be tricky with multi-process, some ptid_t's are not
>> threads.
>
> It's not clear how multi-process is going to work yet (or more likely
> I've forgotten). ?I played with attaching and running several
> processes via gdbserver and all processes appear in "info threads".
> [sidebar: I wouldn't mind "info threads" just showing the threads of
> the current process, otherwise it might get confusing. ?And given that
> "info inferiors" is used to show all the processes IWBN if "inferior
> N" switched to the specified process; a straightforward and intuitive
> mapping from "info threads" + "thread N".]
>
> How about this?
>