Re: [patch] Accessing tls variables across files causes a bug

["Ulrich Weigand" <uweigand@de.ibm.com>]

Jan Kratochvil wrote:

> +	/* SYMBOL_VALUE_ADDRESS should return the translated address.  */

I'm not sure I understand this comment -- the translated address of
a thread-local variable obviously depends on the thread in which it
is evaluated, so how should a single location like SYMBOL_VALUE_ADDRESS
be able to hold that value for all threads?

Otherwise, I guess it makes sense to do that translation for 
LOC_UNRESOLVED TLS symbols in read_var_value, just like it would
be done for LOC_COMPUTED symbols; in both cases assuming evaluation
in the current thread.

> +	    /* SYMBOL_VALUE_ADDRESS should return the translated address.  */
> +	    if (section
> +		&& (section->the_bfd_section->flags & SEC_THREAD_LOCAL) != 0)
> +	      {
> +		printf_filtered (_("a thread-local variable at offset %s "
> +				   "at final address "), paddr_nz (load_addr));
> +		load_addr = target_translate_tls_address (section->objfile,
> +							  load_addr);
> +	      }

Again, I think "at final address" may be misleading; if we give an absolute
address, it should explicitly mention it is relative to the current thread.

On the other hand, I'm wondering if we should perform the resolution here
at all; isn't "info address" also allowed when the target is not actually
running, so we don't even have a current thread?

In the LOC_COMPUTED case, we'd output something like "at offset ...
in the thread-local storage for ...".  For consistency reasons, I'd
prefer to have the same output in the LOC_UNDEFINED case as well.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com