Hi,

just coded it as Vinay Sridhar suggested, thanks.  lookup_block_symbol()
behaves right as it has only the scope of a single BLOCK.

While there should be some more general approach for multiple instances of
a single symbol name in different files this patch has no known regressions.


Regards,
Jan


On Thu, 31 Jul 2008 06:53:40 +0200, Vinay Sridhar wrote:
[...]
> 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