This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA 2/2][master only] gdb/windows-nat.c: Get rid of main_thread_id global
On 4/22/19 10:46 PM, André Pönitz wrote:
> On Mon, Apr 22, 2019 at 06:28:55PM +0100, Pedro Alves wrote:
>> On 4/22/19 4:23 PM, André Pönitz wrote:
>>> On Mon, Apr 22, 2019 at 03:24:46PM +0100, Pedro Alves wrote:
>>>> I don't see the asymmetry (silent at creation, not silent at destruction)
>>>> in this particular case as surprising [...]
>>>
>>> It's not surprising, but it's inconsistent
>>> and causes extra work in
>>> cases one wants to mechanically examine such output.
>>
>> I'm curious about what extra work you're thinking of.
>
> As far as I understand it, any (non-MI) user wanting to keep track of
> running threads would need to find out which events are "not surprising"
> (for which version of GDB...) and mentally (or in code) "generate"
> the "missing" events. That's a kind of "work".
gdb on GNU/Linux already works like I'm suggesting, and has been doing it
for a few years, and I don't think I recall ever hearing complaints about it:
Simple single-threaded "hello world" program:
(gdb) r
Starting program: /home/pedro/brno/pedro/gdb/tests/main
[Inferior 1 (process 13298) exited normally]
(gdb)
Multi-threaded program that exits normally (gdb.threads/schedlock.exp testcase):
(gdb) r
Starting program: build/gdb/testsuite/outputs/gdb.threads/schedlock/schedlock
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff74b8700 (LWP 13984)] <<< extra thread
[Thread 0x7ffff74b8700 (LWP 13984) exited] <<< extra thread exits
[Inferior 1 (process 13980) exited normally]
(gdb)
Threaded program that has the leader thread exit with pthread_exit while
another thread keeps running (gdb.threads/leader-exit.exp testcase):
(gdb) r
Starting program: build/gdb/testsuite/outputs/gdb.threads/leader-exit/leader-exit
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff74b8700 (LWP 13230)] <<<< extra thread
[Thread 0x7ffff7fb6740 (LWP 13226) exited] <<<< leader thread exits (notice LWP == process ID)
[Inferior 1 (process 13226) exited normally]
(gdb)
Note there's some time between the leader exiting, and the process exiting.
If the output were changed like I was suggesting, we'd have something like this,
which I think would be much clearer:
(gdb) r
Starting program: build/gdb/testsuite/outputs/gdb.threads/schedlock/schedlock
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 1.2 (0x7ffff74b8700 (LWP 13984))]
[Thread 1.2 (0x7ffff74b8700 (LWP 13984)) exited]
[Inferior 1 (process 13980) exited normally]
(gdb)
And:
(gdb) r
Starting program: build/gdb/testsuite/outputs/gdb.threads/leader-exit/leader-exit
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 1.2 (0x7ffff74b8700 (LWP 13230))]
[Thread 1.1 (0x7ffff7fb6740 (LWP 13226)) exited]
[Inferior 1 (process 13226) exited normally]
(gdb)
We're going on a tangent, but maybe even say "Thread ... appeared" instead
of "New Thread", for better visual alignment, like:
(gdb) r
Starting program: build/gdb/testsuite/outputs/gdb.threads/schedlock/schedlock
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[Thread 1.2 (0x7ffff74b8700 (LWP 13984)) appeared]
[Thread 1.2 (0x7ffff74b8700 (LWP 13984)) exited]
[Inferior 1 (process 13980) exited normally]
(gdb)
>
>> Can't think of anything significant.
>
> It's not significant, but less surprising to me personally, i.e.
> violating the principle of least astonishment.
>
>> But do note that this discussion does not affect MI.
>
> I understand that, and for thread related notifications MI is sufficient
> for my frontend purposes, but in general MI does not cover all functionality
> of CLI and already this discrepancy is a surprise to some degree. I'd
> rather see the differences go away over time, not to increase.
>
>> So what do you propose? My proposal kept these two ideas in mind:
>>
>> - be quiet wrt to threads with single-threaded programs.
>
> TBH, I don't see the necessity of this requirement. That would be two
> lines of noise per run.
I think I had originally proposed that when I switched gdb's model
to "always a thread", but got pushed back. And I do think the pushback made
sense, particularly when you consider remote debugging targets that don't even
have a concept of threads.
I kind of convinced myself by considering bare metal targets, but also considering
further "execution unit" levels/layers -- say gdb adds native support for fibers, and
the model is that the initial thread has an initial fiber too -- i.e., there's always
a fiber, like there's always a thread. Would we want to automatically announce the
initial fiber as soon as the process starts, even if the process doesn't make
use of fibers?
(gdb) r
Starting program: ...
[New Thread 1.1 ...]
[New Fiber 1.1 ...]
.....
[Fiber 1.1 ... exited]
[Thread 1.1 exited]
[Inferior 1 (process 13226) exited normally]
(gdb)
Or, would we rather be quiet about fibers until something creates a second one,
similarly to how we are quiet about threads until a second thread is created?
And fibers would be one kind of unit of execution. There may be others.
What to do then?
>
>> - inform the user the main thread exited while other threads stay running.
>
> Also here, I don't see enough gain in one suppressed line of output
> to compensate for the inconsistency, this time even with a CLI user hat on.
Thanks,
Pedro Alves