https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65809
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
No, __emutls_v.a certainly is not a user variable, that is an artificial
object, the thread local variable of course lives elsewhere.
You could just drop the stabs for TLS vars on the floor, stabs really doesn't
have extensions to describe the TLS vars. Like:
--- gcc/dbxout.c 2015-02-04 23:36:33.875630546 +0100
+++ gcc/dbxout.c 2015-04-20 12:27:14.579948127 +0200
@@ -2999,6 +2999,8 @@ dbxout_symbol_location (tree decl, tree
if (MEM_P (home) && GET_CODE (XEXP (home, 0)) == SYMBOL_REF)
{
+ if (SYMBOL_REF_TLS_MODEL (XEXP (home, 0)) != TLS_MODEL_NONE)
+ return 0;
if (TREE_PUBLIC (decl))
{
int offs;
The disadvantage of doing that is that (at least on x86_64-linux with
-gstabs+), ptype a etc. will stop working, but one couldn't inspect the
variables there either, you really need DWARF for that.
p &a
$3 = (struct S (*)[10]) 0x0
is of course wrong. So, I'd classify this as a buggy Apple toolchain, but the
above patch might be just ok and not really break anything anyone cares about.
