Hi, 2273f0ac95a79ce29ef42025c63f90e82cf907d7 is the first bad commit commit 2273f0ac95a79ce29ef42025c63f90e82cf907d7 Author: Tom Tromey Date: Tue Oct 15 13:28:57 2013 -0600 change minsyms not to be relocated at read-time [FYI v3 06/10] change minsyms not to be relocated at read-time Message-Id: <1393441273-32268-7-git-send-email-tromey@redhat.com> https://sourceware.org/ml/gdb-patches/2014-02/msg00798.html mv /usr/lib/debug /usr/lib/debug-x echo 'int main(){}'|gcc -pthread -x c - ./gdb -q -ex start -ex 'set debug expr 1' -ex 'p errno' ./a.out 0 UNOP_MEMVAL_TLS TLS type @0x35df7e0 (__thread /* "/lib64/libc.so.6" */ ) 4 OP_LONG Type @0x35df850 (__CORE_ADDR), value 140737345728528 (0x7ffff77fb010) Cannot access memory at address 0xffffef7c9698 -> 0 UNOP_MEMVAL_TLS TLS type @0x3ad9520 (__thread /* "/lib64/libc.so.6" */ ) 4 OP_LONG Type @0x3ad9590 (__CORE_ADDR), value 16 (0x10) $1 = 0 With glibc debuginfo, that is without: mv /usr/lib/debug /usr/lib/debug-x 0 OP_VAR_VALUE Block @0x3b30e70, symbol @0x3b30d10 (errno) $1 = 0 So such case is unrelated to this patch and the regression is not visible with glibc debuginfo installed. I guess all these issues will be solved by Gary Benson's Infinity. But at least for older non-Infinity glibcs GDB should not regress. For the testcase it is important the variable is in objfile with non-zero base address. glibc is a shared library for 'errno' but I found easier for the testcase to use PIE instead of a shlib. For TLS variables in PT_EXEC the regression obviously does not happen. It has been found by a more complete testcase present in Fedora, the fix there also solves more cases where FSF GDB currently cannot resolve 'errno': http://pkgs.fedoraproject.org/cgit/rpms/gdb.git/tree/gdb-6.5-bz185337-resolve-tls-without-debuginfo-v2.patch FAIL: gdb.dwarf2/dw2-errno2.exp: macros=N threads=Y: print errno for core No regressions on {x86_64,x86_64-m32,i686}-fedora26pre-linux-gnu. OK for check-in? Thanks, Jan