This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH/RFC] TLS support part 1
- From: Jim Blandy <jimb at redhat dot com>
- To: Elena Zannoni <ezannoni at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: 02 Oct 2002 20:21:05 -0500
- Subject: Re: [PATCH/RFC] TLS support part 1
- References: <15770.25139.262675.365054@localhost.redhat.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.)