[Bug symtab/25807] New: [readnow] FAIL: gdb.threads/tls.exp: print a_thread_local

[Bug symtab/25807] New: [readnow] FAIL: gdb.threads/tls.exp: print a_thread_local

[vries at gcc dot gnu.org]

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

            Bug ID: 25807
           Summary: [readnow] FAIL: gdb.threads/tls.exp: print
                    a_thread_local
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

When running test-case gdb.threads/tls.exp with target board -readnow, we have:
...
(gdb) print a_thread_local^M
Cannot find thread-local storage for process 0, executable file tls/tls:^M
Cannot find thread-local variables on this target^M
(gdb) FAIL: gdb.threads/tls.exp: print a_thread_local
...
while with native we have:
...
(gdb) print a_thread_local^M
Cannot read `a_thread_local' without registers^M
(gdb) PASS: gdb.threads/tls.exp: print a_thread_local
...

The difference in behaviour can be explained as follows.  Without -readnow, we
have two a_thread_locals, the def and the decl:
...
$ gdb -batch outputs/gdb.threads/tls/tls \
    -ex "maint expand-symtabs" \
    -ex "print a_thread_local" \
    -ex "maint print symbols" \
    | grep "a_thread_local;"
Cannot read `a_thread_local' without registers
 int a_thread_local; computed at runtime
 int a_thread_local; unresolved
...
and with -readnow, we have the opposite order:
...
$ gdb -readnow -batch outputs/gdb.threads/tls/tls  \
    -ex "maint expand-symtabs" \
    -ex "print a_thread_local" \
    -ex "maint print symbols" \
    | grep "a_thread_local;"
Cannot find thread-local storage for process 0, executable file tls/tls:
Cannot find thread-local variables on this target
 int a_thread_local; unresolved
 int a_thread_local; computed at runtime
...

[ With the tentative fix for PR25764, submitted here (
https://sourceware.org/pipermail/gdb-patches/2020-April/167458.html ), we seem
to stabilize that search order and make the test fail without -readnow as well.
]

Anyway, this seems to be a variant of PR24985 - "Cannot print value of global
variable because decl in one CU shadows def in other CU", in the sense that we
probably prefer to find the "computed at runtime" symbol rather than the
"unresolved" symbol.

But, the tentative patch at PR24985 comment 3 doesn't fix this, because that
patch exploits the fact that the decl has an incomplete type, while in this
case the type is complete.

So, I'm filing this as a separate PR.

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

[Bug symtab/25807] [readnow] FAIL: gdb.threads/tls.exp: print a_thread_local

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 12449
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12449&action=edit
Tentative patch

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

[Bug symtab/25807] [readnow] FAIL: gdb.threads/tls.exp: print a_thread_local

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
Patch submitted:
https://sourceware.org/pipermail/gdb-patches/2020-April/167489.html

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

[Bug symtab/25807] [readnow] FAIL: gdb.threads/tls.exp: print a_thread_local

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=de82891ce5b6d2c8109f512cd0732325f4cd0557

commit de82891ce5b6d2c8109f512cd0732325f4cd0557
Author: Tom de Vries <tdevries@suse.de>
Date:   Thu Apr 23 15:42:47 2020 +0200

    [gdb/symtab] Prefer def over decl (inter-CU case)

    When running test-case gdb.threads/tls.exp with target board -readnow, we
    have:
    ...
    (gdb) print a_thread_local^M
    Cannot find thread-local storage for process 0, executable file tls/tls:^M
    Cannot find thread-local variables on this target^M
    (gdb) FAIL: gdb.threads/tls.exp: print a_thread_local
    ...
    while with native we have:
    ...
    (gdb) print a_thread_local^M
    Cannot read `a_thread_local' without registers^M
    (gdb) PASS: gdb.threads/tls.exp: print a_thread_local
    ...

    The difference in behaviour can be explained as follows.  Without -readnow,
we
    have two a_thread_locals, the def and the decl, each in a different CU:
    ...
    $ gdb -batch outputs/gdb.threads/tls/tls \
        -ex "maint expand-symtabs" \
        -ex "print a_thread_local" \
        -ex "maint print symbols" \
        | grep "a_thread_local;"
    Cannot read `a_thread_local' without registers
     int a_thread_local; computed at runtime
     int a_thread_local; unresolved
    ...
    and with -readnow, we have the opposite order:
    ...
    $ gdb -readnow -batch outputs/gdb.threads/tls/tls  \
        -ex "maint expand-symtabs" \
        -ex "print a_thread_local" \
        -ex "maint print symbols" \
        | grep "a_thread_local;"
    Cannot find thread-local storage for process 0, executable file tls/tls:
    Cannot find thread-local variables on this target
     int a_thread_local; unresolved
     int a_thread_local; computed at runtime
    ...

    Fix the FAIL by preferring the def over the decl (something we already do
    intra-CU since the fix for PR24971, commit 93e55f0a03 "[gdb/symtab] Prefer
var
    def over decl").

    Build and reg-tested on x86_64-linux.

    gdb/ChangeLog:

    2020-04-23  Tom de Vries  <tdevries@suse.de>

            PR symtab/25807
            * block.c (best_symbol, better_symbol): Promote to external.
            * block.h (best_symbol, better_symbol): Declare.
            * symtab.c (lookup_symbol_in_objfile_symtabs): Prefer def over
            decl.

    gdb/testsuite/ChangeLog:

    2020-04-23  Tom de Vries  <tdevries@suse.de>

            * gdb.base/decl-before-def-decl.c: New test.
            * gdb.base/decl-before-def-def.c: New test.
            * gdb.base/decl-before-def.exp: New file.

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

[Bug symtab/25807] [readnow] FAIL: gdb.threads/tls.exp: print a_thread_local

[ssbssa at sourceware dot org]

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

Hannes Domani <ssbssa at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ssbssa at sourceware dot org

--- Comment #4 from Hannes Domani <ssbssa at sourceware dot org> ---
(In reply to Sourceware Commits from comment #3)
> The master branch has been updated by Tom de Vries <vries@sourceware.org>:
> 
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;
> h=de82891ce5b6d2c8109f512cd0732325f4cd0557
> 
> commit de82891ce5b6d2c8109f512cd0732325f4cd0557
> Author: Tom de Vries <tdevries@suse.de>
> Date:   Thu Apr 23 15:42:47 2020 +0200
> 
>     [gdb/symtab] Prefer def over decl (inter-CU case)

Can this be closed?

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

[Bug symtab/25807] [readnow] FAIL: gdb.threads/tls.exp: print a_thread_local

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Kevin Buettner <kevinb@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8b87fe90e81f933b7c88e1ea25b02426ee3f58eb

commit 8b87fe90e81f933b7c88e1ea25b02426ee3f58eb
Author: Kevin Buettner <kevinb@redhat.com>
Date:   Wed Apr 23 21:39:28 2025 -0700

    Don't attempt to find TLS address when target has no registers

    This commit fixes two bugs, one of which is Bug 25807, which occurs
    when target_translate_tls_address() is called from
    language_defn::read_var_value in findvar.c.  I found it while testing on
    aarch64; it turned a KFAIL for gdb.threads/tls.exp: print a_thread_local
    into a FAIL due to a GDB internal error.  Now, with this commit in place,
    the KFAIL/FAIL turns into a PASS.

    In addition to the existing test just noted, I've also added a test to
    the new test case gdb.base/tls-nothreads.exp.  It'll be tested, using
    different scenarios, up to 8 times:

    PASS: gdb.base/tls-nothreads.exp: default: force_internal_tls=false: after
exit: print tls_tbss_1
    PASS: gdb.base/tls-nothreads.exp: default: force_internal_tls=true: after
exit: print tls_tbss_1
    PASS: gdb.base/tls-nothreads.exp: static: force_internal_tls=false: after
exit: print tls_tbss_1
    PASS: gdb.base/tls-nothreads.exp: static: force_internal_tls=true: after
exit: print tls_tbss_1
    PASS: gdb.base/tls-nothreads.exp: pthreads: force_internal_tls=false: after
exit: print tls_tbss_1
    PASS: gdb.base/tls-nothreads.exp: pthreads: force_internal_tls=true: after
exit: print tls_tbss_1
    PASS: gdb.base/tls-nothreads.exp: pthreads-static:
force_internal_tls=false: after exit: print tls_tbss_1
    PASS: gdb.base/tls-nothreads.exp: pthreads-static: force_internal_tls=true:
after exit: print tls_tbss_1

    There is a related problem that occurs when target_translate_tls_address
    is called from find_minsym_type_and_address() in minsyms.c.  It can be
    observed when debugging a program without debugging symbols when the
    program is not executing.  I've written a new test for this, but it's
    (also) included in the new test case gdb.base/tls-nothreads.exp, found
    later in this series.  Depending on the target, it can run up to 8
    times using different scenarios.  E.g., on aarch64, I'm seeing these
    PASSes, all of which test this change:

    PASS: gdb.base/tls-nothreads.exp: default: force_internal_tls=false:
stripped: after exit: print (int) tls_tbss_1
    PASS: gdb.base/tls-nothreads.exp: default: force_internal_tls=true:
stripped: after exit: print (int) tls_tbss_1
    PASS: gdb.base/tls-nothreads.exp: static: force_internal_tls=false:
stripped: after exit: print (int) tls_tbss_1
    PASS: gdb.base/tls-nothreads.exp: static: force_internal_tls=true:
stripped: after exit: print (int) tls_tbss_1
    PASS: gdb.base/tls-nothreads.exp: pthreads: force_internal_tls=false:
stripped: after exit: print (int) tls_tbss_1
    PASS: gdb.base/tls-nothreads.exp: pthreads: force_internal_tls=true:
stripped: after exit: print (int) tls_tbss_1
    PASS: gdb.base/tls-nothreads.exp: pthreads-static:
force_internal_tls=false: stripped: after exit: print (int) tls_tbss_1
    PASS: gdb.base/tls-nothreads.exp: pthreads-static: force_internal_tls=true:
stripped: after exit: print (int) tls_tbss_1

    In an earlier version of this commit (v4), I was checking whether the
    target has registers in language_defn::read_var_value in findvar.c and
    in find_minsym_type_and_address in minsyms.c, printing suitable error
    messages in each case.  In his review of this commit for the v4
    series, Tom Tromey asked whether it would be better to do this check
    in target_translate_tls_address.  I had considered doing that for the
    v4 (and earlier) series, but I wanted to print slightly different
    messages at each check.  Also, read_var_value in findvar.c was already
    printing a message in some cases and I had arranged for the later
    check in that function to match the original message.

    However, while I had added a target-has-registers check at two of the
    call sites for target_translate_tls_address, I hadn't added it at the
    third call site which is in dwarf_expr_context::execute_stack_op() in
    dwarf2/expr.c.  I believe that in most cases, this is handled by the
    early check in language_defn::read_var_value...

      else if (sym_need == SYMBOL_NEEDS_REGISTERS && !target_has_registers ())
        error (_("Cannot read `%s' without registers"), var->print_name ());

    ...but it's entirely possible that dwarf_expr_context::execute_stack_op()
    might get called in some other context.  So it makes sense to do the
    target-has-registers check for that case too.  And rather than add yet
    another check at that call site, I decided that moving the check and
    error message to target_translate_tls_address makes sense.

    I had to make the error messages that it prints somewhat more generic.
    In particular, when called from language_defn::read_var_value, the
    message printed by target_translate_tls_address no longer matches the
    earlier message that could be printed (as shown above).  That meant
    that the test cases which check for this message, gdb.threads/tls.exp,
    and gdb.base/tls-nothreads.exp had to be adjusted to account for the
    new message.  Also, I think it's valuable to the user to know (if
    possible) the name of the variable that caused the error, so I've
    added an optional parameter to target_translate_tls_address, providing
    the name of the variable, if it's known.  Therefore, the message
    that's printed when the target-has-registers test fails is one of the
    following:

    When the TLS variable isn't known (due to being called from
    dwarf_expr_context::execute_stack_op):

        "Cannot translate TLS address without registers"

    When the TLS variable is known (from either of the other two call sites
    for target_translate_tls_address):

        "Cannot find address of TLS symbol `%s' without registers"

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25807
    Tested-By: Luis Machado <luis.machado@arm.com>
    Approved-By: Luis Machado <luis.machado@arm.com>

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