Re: [RFA 2/2][master only] gdb/windows-nat.c: Get rid of main_thread_id global

[Pedro Alves <palves at redhat dot com>]

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