I'm getting this exception from a gdb unwinder: #45 0xffffffffffffffff in () Traceback (most recent call last): File "/usr/local/stow/my-gdb/share/gdb/python/gdb/__init__.py", line 91, in execute_unwinders unwind_info = unwinder(pending_frame) File "/home/tromey/firefox-git/gecko/js/src/gdb/mozilla/unwind.py", line 452, in __call__ return self.unwinder_state.unwind(pending_frame) File "/home/tromey/firefox-git/gecko/js/src/gdb/mozilla/unwind.py", line 369, in unwind return self.unwind_exit_frame(pc, pending_frame) File "/home/tromey/firefox-git/gecko/js/src/gdb/mozilla/unwind.py", line 323, in unwind_exit_frame ptd = self.get_tls_per_thread_data() File "/home/tromey/firefox-git/gecko/js/src/gdb/mozilla/unwind.py", line 247, in get_tls_per_thread_data return self.typecache.per_tls_data.value()['mValue'] gdb.error: symbol requires a frame to compute its value The issue here is that the symbol in question (per_tls_data) is thread-local. Accessing this value does not actually require a frame -- just registers. And, since this code is in an unwinder, it seems like it can't really provide a frame. It seems to me that trying to fetch a TLS value in an unwinder ought to be perfectly ok. This came up once before: https://sourceware.org/bugzilla/show_bug.cgi?id=11803 The patch that went in: https://sourceware.org/ml/gdb-patches/2010-09/msg00270.html The original patch, that tried to move the needs-frame requirement: https://sourceware.org/ml/gdb-patches/2010-07/msg00374.html
The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0b31a4bcec2efec9bc8ca40deb61123c52690a2e commit 0b31a4bcec2efec9bc8ca40deb61123c52690a2e Author: Tom Tromey <tom@tromey.com> Date: Fri Jun 3 14:11:08 2016 -0600 PR python/20190 - compute TLS symbol without a frame PR python/20190 arose from an exception I noticed when trying to use the Python unwinder for Spider Monkey in Firefox. The problem is that the unwinder wants to examine the value of a thread-local variable. However, sympy_value rejects this because symbol_read_needs_frame returns true for a TLS variable. This problem arose once before, though in a different context: https://sourceware.org/bugzilla/show_bug.cgi?id=11803 At the time Pedro and Daniel pointed out a simpler way to fix that bug (see links in 20190 if you are interested); but for this new bug I couldn't think of a similar fix and ended up implementing Daniel's other suggestion: https://sourceware.org/ml/gdb-patches/2010-07/msg00393.html That is, this patch makes it possible to detect whether a symbol needs a specific frame, or whether it just needs the inferior to have registers. Built and regtested on x86-64 Fedora 24. 2016-07-26 Tom Tromey <tom@tromey.com> * symtab.c (register_symbol_computed_impl): Update. PR python/20190: * value.h (symbol_read_needs): Declare. (symbol_read_needs_frame): Add comment. * symtab.h (struct symbol_computed_ops) <read_variable>: Update comment. <get_symbol_read_needs>: Rename. Change return type. * findvar.c (symbol_read_needs): New function. (symbol_read_needs_frame): Rewrite. (default_read_var_value): Use symbol_read_needs. * dwarf2loc.c (struct symbol_needs_baton): Rename. <needs>: Renamed from needs_frame. Changed type. (needs_frame_read_addr_from_reg, symbol_needs_get_reg_value) (symbol_needs_read_mem, symbol_needs_frame_base) (symbol_needs_frame_cfa, symbol_needs_tls_address) (symbol_needs_dwarf_call): Rename. (needs_dwarf_reg_entry_value): Update. (symbol_needs_ctx_funcs, dwarf2_loc_desc_get_symbol_read_needs): Rename and update. (locexpr_get_symbol_read_needs, loclist_symbol_needs): Likewise. (dwarf2_locexpr_funcs, dwarf2_loclist_funcs): Update. * defs.h (enum symbol_needs_kind): New. 2016-07-26 Tom Tromey <tom@tromey.com> PR python/20190: * gdb.threads/tls.exp (check_thread_local): Add python symbol test.
Fixed.