Accessing tls variables across files causes a bug

[Vinay Sridhar <vinay at linux dot vnet dot ibm dot com>]

Hi All,

We came across this bug when debugging tls variables.

------------------------
Consider file1.c : 
------------------------
#include<...>
...
__thread int thr;
int stopHere;
...
void foo()
{
stopHere=8;
}

main()
{
thr = 0;
foo();
}

-------------------------
Now consider file2.c : 
-------------------------

__thread char myChar;
extern __thread int thr;

void foo1()
{
myChar = 'a' + thr;
}


On compiling these 2 and creating the executable, the bug is produced on
running the following commands : 

1. gdb <executable>
2. b 8 //at the stopHere part of file1
3. run
4. print thr //prints value of thr
5. print myChar
6. print thr

Now on the final print command, you get a "Cannot access memory at
address 0x4"

The reason for this is "thr", being a tls variable, is stored as an
offset in the minsymtab. So for the "extern thr", gdb sets it to
LOC_UNRESOLVED and by convention, looks up minsymtab to find its
address. Here it justs picks up the offset and tries to dereference it.
This works fine for other global variables that are extern but fails for
"tls" variables that are extern. 

What I propose is that in "lookup_symbol_aux_symtabs()" @symtab.c, when
the tls variable is to be looked up, once we find it in the current
file's symtab and is at LOC_UNRESOLVED, we ignore it and look further in
other symtabs of the object file as well and find one that has
LOC_COMPUTED, i.e, we look into the symtab of the file which has defined
this and retrieve the symbol information from this block of the objfile.
This will be restricted to tls variables only. 

Is this fix acceptable?

Request for Comments..

Regards,
Vinay 

Vinay Sridhar,
IBM-Linux Technology Centre
vinay@linux.vnet.ibm.com