Subject: gdb: "cannot find thread-local storage" from Python, not from CLI
Date: Wed, 21 Jun 2017 09:44:55 -0400
Package: gdb
Version: 7.12-6
Severity: normal
Tags: upstream
Attempting to read thread-local variables (e.g. errno) from the
Python interface fails with "Cannot find thread-local storage", but
reading the same variable from the (gdb) prompt works. Transcript:
$ cat test.c
#include <stdio.h>
#include <errno.h>
int main(void)
{
printf("%d\n", errno);
}
$ gcc -g test.c
$ gdb ./a.out
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./a.out...done.
(gdb) b main
Breakpoint 1 at 0x704: file test.c, line 6.
(gdb) r
Starting program: /home/zack/a.out
Breakpoint 1, main () at test.c:6
6 printf("%d\n", errno);
(gdb) p errno
$1 = 0
(gdb) pi
>>> gdb.parse_and_eval('errno')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
gdb.error: Cannot find thread-local storage for process 8486, shared library /lib/x86_64-linux-gnu/libc.so.6:
Cannot find thread-local variables on this target
I observe the same behavior with 7.12-6 (unstable) and 8.0-1 (experimental).
-- System Information:
Debian Release: 9.0
APT prefers unstable
APT policy: (501, 'unstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (101, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages gdb depends on:
ii libbabeltrace-ctf1 1.5.2-1
ii libbabeltrace1 1.5.2-1
ii libc6 2.24-12
ii libexpat1 2.2.1-1
ii liblzma5 5.2.2-1.2+b1
ii libncurses5 6.0+20161126-1
ii libpython3.5 3.5.3-3
ii libreadline7 7.0-3
ii libtinfo5 6.0+20161126-1
ii zlib1g 1:1.2.8.dfsg-5
Versions of packages gdb recommends:
ii libc6-dbg [libc-dbg] 2.24-12
Versions of packages gdb suggests:
pn gdb-doc <none>
ii gdbserver 7.12-6
-- no debconf information
Acknowledgement sent
to Zack Weinberg <[email protected]>:
Extra info received and forwarded to list. Copy sent to Héctor Orón Martínez <[email protected]>.
(Wed, 21 Jun 2017 14:15:02 GMT) (full text, mbox, link).
Subject: correction: errno is special, python is not the problem
Date: Wed, 21 Jun 2017 09:56:07 -0400
Control: retitle -1 gdb: x86-64: "cannot find thread-local variables
on this target"
Further experimentation indicates that this is a problem with
thread-local variables in general and there's something special about
'errno' that makes it appear to work; the Python interface is not the
problem. For instance:
$ cat test.c
#include <stdio.h>
#include <errno.h>
static _Thread_local int foo;
int main(void)
{
printf("%d %d\n", errno, foo);
}
$ gcc -g test.c
$ gdb ./a.out
...
(gdb) b main
Breakpoint 1 at 0x749: file test.c, line 6.
(gdb) r
Starting program: /home/zack/a.out
Breakpoint 1, main () at test.c:6
6 printf("%d %d\n", errno, foo);
(gdb) p errno
$1 = 0
(gdb) p foo
Cannot find thread-local storage for process 13090, executable file
/home/zack/a.out:
Cannot find thread-local variables on this target
Changed Bug title to 'gdb: x86-64: "cannot find thread-local variables' from 'gdb: "cannot find thread-local storage" from Python, not from CLI'.
Request was from Zack Weinberg <[email protected]>
to [email protected].
(Wed, 21 Jun 2017 14:15:02 GMT) (full text, mbox, link).