[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)

iains at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Mon Apr 20 10:47:00 GMT 2015


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.


More information about the Gcc-bugs mailing list