public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug symtab/25807] New: [readnow] FAIL: gdb.threads/tls.exp: print a_thread_local
@ 2020-04-09 11:52 vries at gcc dot gnu.org
  2020-04-09 11:57 ` [Bug symtab/25807] " vries at gcc dot gnu.org
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: vries at gcc dot gnu.org @ 2020-04-09 11:52 UTC (permalink / raw)
  To: gdb-prs

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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2024-01-26 13:59 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-09 11:52 [Bug symtab/25807] New: [readnow] FAIL: gdb.threads/tls.exp: print a_thread_local vries at gcc dot gnu.org
2020-04-09 11:57 ` [Bug symtab/25807] " vries at gcc dot gnu.org
2020-04-09 14:31 ` vries at gcc dot gnu.org
2020-04-23 13:42 ` cvs-commit at gcc dot gnu.org
2024-01-26 13:59 ` ssbssa at sourceware dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).