SUMMARY
When attempting to debug a Qt c++ application on KDE Neon 5.20.3 using gdb, it prints the following error:
Error while reading shared library symbols for /lib/x86_64-linux-gnu/libpthread.so.0:
Cannot find user-level thread for LWP 5775: generic error

STEPS TO REPRODUCE
1. git clone https://github.com/mumble-voip/mumble.git
2. cd mumble && git submodule update --recursive --init
3. Install dependencies as stated by https://github.com/mumble-voip/mumble/blob/master/docs/dev/build-instructions/build_linux.md
4. mkdir build && cd build
5. cmake -Dtranslations=OFF -DCMAKE_BUILD_TYPE=Debug -Doverlay-xcompile=OFF ..
6. Debug application mumble using gdb

OBSERVED RESULT
Have a look at https://stackoverflow.com/questions/64898997/gdb-only-finds-some-debug-symbols?noredirect=1 for a full description of the problem.

On a completely fresh setup, the debugged program will start but then soon will abort with the error message

Error while reading shared library symbols for /lib/x86_64-linux-gnu/libpthread.so.0:
Cannot find user-level thread for LWP 5482: generic error


EXPECTED RESULT
Debugging the application without issues (no crashes and being able to print a proper backtrace)


SOFTWARE/OS VERSIONS
(These are the specs of my VM, but on real hardware the result is the same)
Operating System: KDE neon 5.20
KDE Plasma Version: 5.20.3
KDE Frameworks Version: 5.75.0
Qt Version: 5.15.1
Kernel Version: 5.4.0-54-generic
OS Type: 64-bit
Processor: 1 × Intel® Core™ i7-4770 CPU @ 3.40GHz
Memory: 2,9 GiB of RAM
Graphics Processor: llvmpipe

ADDITIONAL INFORMATION
I was able to debug this specific application before just fine also using KDE Neon (though the last time it worked for sure was with 5.20.2 or perhaps even 5.19.x)

I experienced this issue on my main machine but just checked that in a VM in which I performed a fresh installation of KDE Neon, the problem is the same.
Furthermore I verified that using a VM running plain Ubuntu 20.04, it works as expected.

The issue seems to be only appear as soon as a second thread in my application comes into play.

I am also not entirely sure whether this might be a Qt problem or a general problem of libpthread

dlocate libpthread.so.0
libc6:amd64: /lib/x86_64-linux-gnu/libpthread.so.0

ll /lib/x86_64-linux-gnu/ | grep thread
lrwxrwxrwx   1 root root        26 Nov 30  2019 libfftw3f_threads.so.3 -> libfftw3f_threads.so.3.5.8
-rw-r--r--   1 root root     35368 Nov 30  2019 libfftw3f_threads.so.3.5.8
lrwxrwxrwx   1 root root        14 Mär 12  2020 libgpgme-pthread.so.11 -> libgpgme.so.11
-rw-r--r--   1 root root      2870 Jun 16 13:21 libgthread-2.0.a
lrwxrwxrwx   1 root root        19 Jun 16 13:21 libgthread-2.0.so -> libgthread-2.0.so.0
lrwxrwxrwx   1 root root        26 Jun 16 13:21 libgthread-2.0.so.0 -> libgthread-2.0.so.0.6400.3
-rw-r--r--   1 root root     14488 Jun 16 13:21 libgthread-2.0.so.0.6400.3
-rwxr-xr-x   1 root root    157224 Aug 17 22:02 libpthread-2.31.so*
-rw-r--r--   1 root root   6587378 Aug 17 22:02 libpthread.a
lrwxrwxrwx   1 root root        37 Aug 17 22:02 libpthread.so -> /lib/x86_64-linux-gnu/libpthread.so.0*
lrwxrwxrwx   1 root root        18 Aug 17 22:02 libpthread.so.0 -> libpthread-2.31.so*
-rw-r--r--   1 root root     39896 Aug 17 22:02 libthread_db-1.0.so
lrwxrwxrwx   1 root root        39 Aug 17 22:02 libthread_db.so -> /lib/x86_64-linux-gnu/libthread_db.so.1
lrwxrwxrwx   1 root root        19 Aug 17 22:02 libthread_db.so.1 -> libthread_db-1.0.so