Re: [PATCH][gdb/testsuite] Fix check-libthread-db.exp FAILs with glibc 2.33

[Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>]

On 2021-07-07 10:09 a.m., Tom de Vries wrote:
> Hi,
> 
> When running test-case gdb.threads/check-libthread-db.exp on openSUSE
> Tumbleweed with glibc 2.33, I get:
> ...
> (gdb) maint check libthread-db^M
> Running libthread_db integrity checks:^M
>   Got thread 0x7ffff7c79b80 => 9354 => 0x7ffff7c79b80; errno = 0 ... OK^M
> libthread_db integrity checks passed.^M
> (gdb) FAIL: gdb.threads/check-libthread-db.exp: user-initiated check: libpthread.so not initialized (pattern 2)
> ...
> 
> The test-case expects instead:
> ...
>   Got thread 0x0 => 9354 => 0x0 ... OK^M
> ...
> which is what I get on openSUSE Leap 15.2 with glibc 2.26, and what is
> described in the test-case like this:
> ...
>     # libthread_db should fake a single thread with th_unique == NULL.
> ...
> 
> Using a breakpoint on check_thread_db_callback we can compare the two
> scenarios, and find that in the latter case we hit this code in glibc function
> iterate_thread_list in nptl_db/td_ta_thr_iter.c:
> ...
>   if (next == 0 && fake_empty)
>     {
>       /* __pthread_initialize_minimal has not run.  There is just the main
>          thread to return.  We cannot rely on its thread register.  They
>          sometimes contain garbage that would confuse us, left by the
>          kernel at exec.  So if it looks like initialization is incomplete,
>          we only fake a special descriptor for the initial thread.  */
>       td_thrhandle_t th = { ta, 0 };
>       return callback (&th, cbdata_p) != 0 ? TD_DBERR : TD_OK;
>     }
> ...
> while in the former case we don't because this preceding statement doesn't
> result in next == 0:
> ...
>   err = DB_GET_FIELD (next, ta, head, list_t, next, 0);
> ...
> 
> Note that the comment mentions __pthread_initialize_minimal, but in both cases
> it has already run before we hit the callback, so it's possible the comment is
> no longer accurate.
> 
> Anyway, the results do not look wrong, so fix this by updating the regexp
> patterns to agree with what libthread-db is telling us.
> 
> Tested on x86_64-linux, both with glibc 2.33 and 2.26.
> 
> Any comments?

I got a bit lost in the glibc code, but I am wondering if this change in
behavior might have been caused by this glibc change:

  https://gitlab.com/gnutools/glibc/-/commit/1daccf403b1bd86370eb94edca794dc106d02039

Before this, the stack_user list was global variables.  This is one of
the two lists that get walked to enumerate the threads.  Since it isn't
initialized statically, it got placed in .bss and is zeroed-out by
default, hence why thread-db expected to read next == 0, I guess.

Or, it may be that the moment that this nptl minimal initialization is
done has changed, at least relative to where we do our checks.  It looks
like __pthread_initialize_minimal_internal is called as a constructor.
Has it always been this way?  By the time we stop on the solib load
event, have the constructors of the lib ran?

In any case, I agree that this looks benign, the regexp checks we have
exactly one thread.  But I would still be curious to know the real
reason for the change in behavior.

Simon