On Tue, Dec 22, 2020 at 08:04:31PM +0000, Al Viro wrote: > FWIW, on debian/mips64el (both stretch and buster) the test fails with the > distro kernels (4.9- and 4.19-based) as well as with 5.10-rc1 and > 5.10-rc1+that series, all in the same way: > [Current thread is 1 (LWP 4154)] > (gdb) p/x foo > Cannot find thread-local storage for LWP 4154, executable file <pathname> > Cannot find thread-local variables on this target > > buster has libc6-2.28, so that should be fine for the test in question > (libthread_db definitely recent enough). That was n32 gdb; considering > how much time it had taken to build that sucker I hadn't tried o32 > yet. > > Note that it's not just with native coredumps - gcore-produced ones give > the same result. That was gdb from binutils-gdb.git; I'm not familiar > with gdb guts to start debugging it, so if you have any suggestions > in that direction that do not include a full rebuild... In any case, > I won't get around to that until the next week. > > Incidentally, build time is bloody awful - 3 days, with qemu-3.1 on > 3.5GHz amd64 host, all spent pretty much entirely in userland (both > from guest and host POV). g++-8 is atrociously slow... > > That said, I don't see what in that series could possibly mess the > things up for tls, while leaving the registers working; the only > thing that realistically might've been fucked up is prstatus layout > (and possibly size), and that would've screwed the registers as > well. ... and it smells like the damn thing needs n32 debug info from libthread_db.so and/or libpthread.so. Which is not packaged by debian libc6 mips64el build. Sorry, any debugging of that crap is going to happen in January ;-/
