Re: [PATCH/RFC] TLS support part 1

[Jim Blandy <jimb at redhat dot com>]

Elena Zannoni <ezannoni@redhat.com> writes:
> @@ -611,8 +611,16 @@ enum address_class
>      target-specific method. This is used only by hppa.  */
>  
>    LOC_HP_THREAD_LOCAL_STATIC,
> +
> +  /* Value is at a thread-specific location calculated by a
> +     target-specific method.  SYMBOL_OBJFILE gives the object file
> +     in which the symbol is defined; the symbol's value is the
> +     o
> +  /* Value is at a thread-specific location calculated by a
> +     target-specific method.  SYMBOL_OBJFILE gives the object file
> +     in which the symbol is defined; the symbol's value is the
> +     offset into that objfile's thread-local storage for the current
> +     thread.  */
> +      
>    LOC_THREAD_LOCAL_STATIC,
>  
>    /* The variable does not actually exist in the program.

Busted patch? 

> @@ -684,6 +692,12 @@ struct symbol
>    {
>      /* Used by LOC_BASEREG and LOC_BASEREG_ARG.  */
>      short basereg;
> +
> +    /* The objfile in which this symbol is defined.  To find a
> +       thread-local variable (e.g., a variable declared with the
> +       `__thread' storage class), we may need to know which object
> +       file it's in.  */
> +    struct objfile *objfile;
>    }
>    aux_value;

I think probably every element of aux_value should have a comment
indicating which sorts of address classes it's valid for; this comment
mentions thread-local variables, but it should probably be more
explicit about the fact that objfile is valid only for
LOC_THREAD_LOCAL_STATIC.

(I think the comment in your patch here comes directly from my early
patch, so I'm complaining about my own writing here.  Oh well.)