From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2104 invoked by alias); 3 Oct 2002 01:37:24 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 2090 invoked from network); 3 Oct 2002 01:37:22 -0000 Received: from unknown (HELO zenia.red-bean.com) (66.244.67.22) by sources.redhat.com with SMTP; 3 Oct 2002 01:37:22 -0000 Received: (from jimb@localhost) by zenia.red-bean.com (8.11.6/8.11.6) id g931L6g20779; Wed, 2 Oct 2002 20:21:06 -0500 To: Elena Zannoni Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH/RFC] TLS support part 1 References: <15770.25139.262675.365054@localhost.redhat.com> From: Jim Blandy Date: Wed, 02 Oct 2002 18:37:00 -0000 In-Reply-To: <15770.25139.262675.365054@localhost.redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.90 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-10/txt/msg00094.txt.bz2 Elena Zannoni 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.)