[PATCH/RFC] TLS support part 1

[Elena Zannoni]

Jim Blandy writes:
 > 
 > 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? 
 > 

Yeah, I copied the diff into this email....silly fingers.

 > > @@ -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.
 > 

Yes, that would be a good idea.

 > (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.)

yes :-) split personality disorder?

Elena