https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65809
--- Comment #7 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #6)
> 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,
there's nothing apple-specific about this - or even Darwin-specific.
The problem will exist for all the toolchains that use emutls (*iff* they are
interested in STABs debug).
AFAICT ld64 just detected an inconsistency that has gone un-noticed elsewhere,
if that's really a ld64 bug we should file it…
OTOH, I agree that there's probably little interest in STABs - even on Darwin
it's only relevant for the most ancient system on the horizon.
> the above patch might be just ok and not really break anything anyone cares
> about.
let's test that out.
