[Bug varobj/18564] regression in showing __thread so extern variable

["philippe.waroquiers at skynet dot be" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=18564

--- Comment #4 from philippe.waroquiers at skynet dot be ---
A few more observations:

1. I am wondering why the attached reproducer produces a problem,
   while the test gdb.threads/tls-shared.exp
   seems very similar. The (main) difference I see is that tls-shared.exp
   does not really start some threads.

2. when observing what travels between gdb and gdbsrv, one see that effectively
   the load address of the .so is (wrongly?) added to obtain the offset
   used for get tls addr:
   good:  getpkt ("qGetTLSAddr:988,0,4022968");  [no ack] 
   bad: getpkt ("qGetTLSAddr:9a2,4025000,4022968");  [no ack] 

3. Same problem with errno (which cannot be printed, once some threads are
started)
 (gdb) info address errno
    good (7.7): 
      Symbol "errno" is a thread-local variable at offset 0x8 in the
thread-local storage for
`/usr/lib/debug/lib/i386-linux-gnu/i686/cmov/libc-2.19.so'.

    bad  (7.9.1): Symbol "errno" is a thread-local variable at offset
0xb7df4008 in the thread-local storage for
`/usr/lib/debug/lib/i386-linux-gnu/i686/cmov/libc-2.19.so'.
    (gdb) p errno
Cannot access memory at address 0x6f3e5b44

4. when setting a break in main, info address errno gives:
(gdb) info address errno
Symbol "errno" is a thread-local variable at offset 0x8 in the thread-local
storage for `/lib/i386-linux-gnu/i686/cmov/libc.so.6'.
(gdb) 

but then when reaching the break at line 9, we obtain:
(gdb) info address errno
Symbol "errno" is a thread-local variable at offset 0xb7df4008 in the
thread-local storage for
`/usr/lib/debug/lib/i386-linux-gnu/i686/cmov/libc-2.19.so'.
(gdb) 

So, starting threads and/or loading the debug info for libc makes the offset
of errno 'wrong'.

-- 
You are receiving this mail because:
You are on the CC list for the bug.