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

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

[philippe.waroquiers at skynet dot be]

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

            Bug ID: 18564
           Summary: regression in showing __thread so extern variable
           Product: gdb
           Version: 7.9
            Status: NEW
          Severity: normal
          Priority: P2
         Component: varobj
          Assignee: unassigned at sourceware dot org
          Reporter: philippe.waroquiers at skynet dot be
  Target Milestone: ---

Created attachment 8378
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8378&action=edit
reproduces bug showing __thread int so_extern   defined in a .so

Between gdb 7.7 and gdb 7.8/7.9, a regression appeared in the display
of __thread variables defined in a shared object.
(I think it regressed in 7.8, bug is still present in 7.9).

To reproduce:
# untar the attachment
tar xf soextern.tar
# compile and link:
./comp
# and reproduce:
gdb ./gtls
break 9
run
p &so_extern
# here the program has printed:
address is 0xb7df3b3c
# while gdb prints:
$1 = (int *) 0x6fdcbb3c
#same problem for the second thread
address is 0xb75f2b3c
$2 = (int *) 0x6f5cab3c
# if you try to print the variable, it fails.
(gdb) p so_extern
Cannot access memory at address 0x6f5cab3c

This is working with gdb 7.7 on Debian 8, x86,
compared with gdb 7.9.1 self compiled, which fails.
Note that this was first detected on various Valgrind buildbots,
where the regression test gdbserver/hgtls started to fail
with gdb versions >= 7.8, but I have not tested myself with 7.8

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

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

[philippe.waroquiers at skynet dot be]

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

--- Comment #1 from philippe.waroquiers at skynet dot be ---
I just checked on Ubuntu 14 (amd64), comparing
gdb 7.7.1 (Ubuntu package)
with 7.9.50.20150608-cvs.
Same problem/same regression.

Problem also detected on s390x, with GNU gdb (GDB) Fedora 7.8.2-38.fc21

So, the problem looks to be in platform independent code.

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

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

[mjw at redhat dot com]

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

Mark Wielaard <mjw at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjw at redhat dot com

--- Comment #2 from Mark Wielaard <mjw at redhat dot com> ---
2273f0ac95a79ce29ef42025c63f90e82cf907d7 is the first bad commit
commit 2273f0ac95a79ce29ef42025c63f90e82cf907d7
Author: Tom Tromey <tromey@redhat.com>
Date:   Tue Oct 15 13:28:57 2013 -0600

    change minsyms not to be relocated at read-time

    This removes the runtime offsets from minsyms.  Instead, these offsets
    will now be applied whenever the minsym's address is computed.

    This patch redefines MSYMBOL_VALUE_ADDRESS to actually use the offsets
    from the given objfile.  Then, it updates all the symbol readers,
    changing them so that they do not add in the section offset when
    creating the symbol.

    This change also lets us remove relocation of minsyms from
    objfile_relocate1 and also msymbols_sort.

    2014-02-26  Tom Tromey  <tromey@redhat.com>

        * minsyms.c (msymbols_sort): Remove.
        * minsyms.h (msymbols_sort): Remove.
        * objfiles.c (objfile_relocate1): Don't relocate minsyms.
        * symtab.h (MSYMBOL_VALUE_ADDRESS): Use objfile offsets.
        * elfread.c (elf_symtab_read): Don't add section offsets.
        * xcoffread.c (record_minimal_symbol): Don't add section offset
        to minimal symbol address.
        * somread.c (text_offset, data_offset): Remove.
        (som_symtab_read): Don't add section offsets to minimal symbol
        addresses.
        * coff-pe-read.c (add_pe_forwarded_sym, read_pe_exported_syms):
        Don't add section offsets to minimal symbols.
        * coffread.c (coff_symtab_read): Don't add section offsets
        to minimal symbol addresses.
        * machoread.c (macho_symtab_add_minsym): Don't add section offset
        to minimal symbol addresses.
        * mipsread.c (read_alphacoff_dynamic_symtab): Don't add
        section offset to minimal symbol addresses.
        * mdebugread.c (parse_partial_symbols): Don't add section
        offset to minimal symbol addresses.
        * dbxread.c (read_dbx_dynamic_symtab): Don't add section
        offset to minimal symbol addresses.

:040000 040000 f4063f5d4257ba2bc4a35d026cd3df4fe1f865b8
deb71e85a8c10482fb81add9a4adb319b2198acb M      gdb
bisect run success

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

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

[mjw at redhat dot com]

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

--- Comment #3 from Mark Wielaard <mjw at redhat dot com> ---
Somewhat random attempt at a fix based on the observation of Philippe that in
the patch, elfread.c, there is one mention of 'non-TLS' and in that case the
offset was added previously.

diff --git a/gdb/findvar.c b/gdb/findvar.c
index a2a7bb7..e153989 100644
--- a/gdb/findvar.c
+++ b/gdb/findvar.c
@@ -582,7 +582,14 @@ default_read_var_value (struct symbol *var, struct
frame_info *frame)
        obj_section = MSYMBOL_OBJ_SECTION (lookup_data.result.objfile, msym);
        if (obj_section
            && (obj_section->the_bfd_section->flags & SEC_THREAD_LOCAL) != 0)
-         addr = target_translate_tls_address (obj_section->objfile, addr);
+         {
+           CORE_ADDR offset;
+           struct objfile *objfile = obj_section->objfile;
+           offset = ANOFFSET (objfile->section_offsets,
+                              gdb_bfd_section_index (objfile->obfd,
+                                                     obj_section));
+           addr = target_translate_tls_address (objfile, addr - offset);
+         }
       }
       break;

With this the testcase passes again.

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

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

[philippe.waroquiers at skynet dot be]

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.

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

[philippe.waroquiers at skynet dot be]

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

--- Comment #5 from philippe.waroquiers at skynet dot be ---
(In reply to Mark Wielaard from comment #3)

> +	    addr = target_translate_tls_address (objfile, addr - offset);
Assuming this is the good fix, then a similar fix is probably needed in
printcmd.c, to show the offset in the tls storage.


Also, maybe an alternative solution might be to use 
 MSYMBOL_VALUE_RAW_ADDRESS(symbol) for tls variables,
rather than MSYMBOL_VALUE_ADDRESS or BMSYMBOL_VALUE_ADDRESS
(so as to avoid adding relocation to later substract it).

In symtab.h, there is also no indication in the comment that LOC_UNRESOLVED
is used for thread variables/tls storage.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From gdb-prs-return-18527-listarch-gdb-prs=sources.redhat.com@sourceware.org Fri Aug 28 18:02:30 2015
Return-Path: <gdb-prs-return-18527-listarch-gdb-prs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb-prs@sources.redhat.com
Received: (qmail 735 invoked by alias); 28 Aug 2015 18:02:29 -0000
Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-prs.sourceware.org>
List-Subscribe: <mailto:gdb-prs-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-prs/>
List-Post: <mailto:gdb-prs@sourceware.org>
List-Help: <mailto:gdb-prs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: gdb-prs-owner@sourceware.org
Delivered-To: mailing list gdb-prs@sourceware.org
Received: (qmail 130881 invoked by uid 48); 28 Aug 2015 18:02:29 -0000
From: "msebor at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug c++/18881] New: bogus 'Cannot resolve function foo to any
 overloaded instance'
Date: Fri, 28 Aug 2015 18:02:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: c++
X-Bugzilla-Version: 7.8
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: msebor at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-18881-4717@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-q3/txt/msg00231.txt.bz2
Content-length: 2634

https://sourceware.org/bugzilla/show_bug.cgi?id\x18881

            Bug ID: 18881
           Summary: bogus 'Cannot resolve function foo to any overloaded
                    instance'
           Product: gdb
           Version: 7.8
            Status: NEW
          Severity: normal
          Priority: P2
         Component: c++
          Assignee: unassigned at sourceware dot org
          Reporter: msebor at redhat dot com
  Target Milestone: ---

In the test case below, GNU gdb (GDB) Fedora 7.8.2-38.fc21 fails to resolve the
call to foo() in the ternary ?:  expression even though it resolves it
successfully on its own.  This makes debugging GCC difficult because it
prevents gdb from printing the values of some of the tree-checking macros. For
example:

(gdb) macro expand DECL_IS_BUILTIN((tree)expr)
expands to: (((IS_ADHOC_LOC (((contains_struct_check (((tree)expr),
(TS_DECL_MINIMAL), "/home/msebor/scm/fsf/gcc-66516/gcc/c-family/c-common.c",
12896, __FUNCTION__))->decl_minimal.locus))) ? get_location_from_adhoc_loc
(line_table, ((contains_struct_check (((tree)expr), (TS_DECL_MINIMAL),
"/home/msebor/scm/fsf/gcc-66516/gcc/c-family/c-common.c", 12896,
__FUNCTION__))->decl_minimal.locus)) : (((contains_struct_check (((tree)expr),
(TS_DECL_MINIMAL), "/home/msebor/scm/fsf/gcc-66516/gcc/c-family/c-common.c",
12896, __FUNCTION__))->decl_minimal.locus))) <= ((source_location) 1))
(gdb) p DECL_IS_BUILTIN((tree)expr)
Cannot resolve function contains_struct_check to any overloaded instance

Test case:

$ cat t.cpp && gcc -g3 t.cpp && gdb -batch -ex 'b bar' -ex r -ex 'p FOO1(b)'
-ex 'p FOO2(b)' -ex 'p foo((A)b)' -ex 'p foo((A)b) ? foo((A)b) : foo((A)b)'
a.out
struct U { };

typedef U *A;
typedef const U *B;

A foo (A a) { return a; }
B foo (B b) { return b; }

#define FOO1(x) foo ((A)x)
#define FOO2(x) foo (FOO1 (x)) ? foo (FOO1 (x)) : foo (FOO1 (x))

int bar (B b)
{
    if (FOO2 (b))
        return 1;
    return 0;
}

int main ()
{
    U u = { };
    return bar (&u);
}
Breakpoint 1 at 0x40051e: file t.cpp, line 14.
warning: the debug information found in
"/usr/lib/debug//lib64/ld-2.20.so.debug" does not match
"/lib64/ld-linux-x86-64.so.2" (CRC mismatch).

warning: the debug information found in
"/usr/lib/debug//lib64/libc-2.20.so.debug" does not match "/lib64/libc.so.6"
(CRC mismatch).


Breakpoint 1, bar (b=0x7fffffffdeff) at t.cpp:14
14          if (FOO2 (b))
$1 = (U *) 0x7fffffffdeff
Cannot resolve function foo to any overloaded instance
$2 = (U *) 0x7fffffffdeff
Cannot resolve function foo to any overloaded instance

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

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

[mjw at redhat dot com]

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

--- Comment #6 from Mark Wielaard <mjw at redhat dot com> ---
Philippe posted a patch plus testcase:
https://sourceware.org/ml/gdb-patches/2015-08/msg00855.html

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

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

[philippe.waroquiers at skynet dot be]

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

philippe.waroquiers at skynet dot be changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from philippe.waroquiers at skynet dot be ---
Fix pushed as
commit 5382cfab6110741b8ba36965b30334c00d8f9409
Author: Philippe Waroquiers <philippe.waroquiers@skynet.be>
Date:   Tue Sep 15 21:02:15 2015 +0200

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