Commit Graph

6 Commits

Author SHA1 Message Date
Johnny Chen 24086bc93b Second batch of adding @dsym_test/@dwarf_test decorators to existing test cases.
Plus some minor cleanup of test method names.
Third and final batch is coming.

llvm-svn: 154197
2012-04-06 19:54:10 +00:00
Greg Clayton 2fc93eabf7 <rdar://problem/10338439>
This is the actual fix for the above radar where global variables that weren't
initialized were not being shown correctly when leaving the DWARF in the .o 
files. Global variables that aren't intialized have symbols in the .o files
that specify they are undefined and external to the .o file, yet document the
size of the variable. This allows the compiler to emit a single copy, but makes
it harder for our DWARF in .o files with the executable having a debug map
because the symbol for the global in the .o file doesn't exist in a section
that we can assign a fixed up linked address to, and also the DWARF contains
an invalid address in the "DW_OP_addr" location (always zero). This means that
the DWARF is incorrect and actually maps all such global varaibles to the
first file address in the .o file which is usually the first function. So we
can fix this in either of two ways: make a new fake section in the .o file
so that we have a file address in the .o file that we can relink, or fix the 
the variable as it is created in the .o file DWARF parser and actually give it
the file address from the executable. Each variable contains a 
SymbolContextScope, or a single pointer that helps us to recreate where the
variables came from (which module, file, function, etc). This context helps
us to resolve any file addresses that might be in the location description of
the variable by pointing us to which file the file address comes from, so we
can just replace the SymbolContextScope and also fix up the location, which we
would have had to do for the other case as well, and update the file address.
Now globals display correctly.

The above changes made it possible to determine if a variable is a global
or static variable when parsing DWARF. The DWARF emits a DW_TAG_variable tag
for each variable (local, global, or static), yet DWARF provides no way for
us to classify these variables into these categories. We can now detect when
a variable has a simple address expressions as its location and this will help
us classify these correctly.

While making the above changes I also noticed that we had two symbol types:
eSymbolTypeExtern and eSymbolTypeUndefined which mean essentially the same
thing: the symbol is not defined in the current object file. Symbol objects
also have a bit that specifies if a symbol is externally visible, so I got
rid of the eSymbolTypeExtern symbol type and moved all code locations that
used it to use the eSymbolTypeUndefined type.
 

llvm-svn: 144489
2011-11-13 04:15:56 +00:00
Johnny Chen 606e049cca Add a negative self.expect() to verify that the bug has been fixed.
rdar://problem/9747668

llvm-svn: 137129
2011-08-09 17:48:29 +00:00
Johnny Chen 628d84005a Add rdar://problem/9747668 info for "target variable g_marked_spot.y" command.
llvm-svn: 134772
2011-07-08 23:38:39 +00:00
Johnny Chen 98a5ddd006 Add test scenarios for 'target variable' command into TestGlobalVariables.py file.
llvm-svn: 134771
2011-07-08 23:33:36 +00:00
Johnny Chen 23beac3368 Move global_variables dir to lang/c and foundation dir to lang/objc.
llvm-svn: 133883
2011-06-25 20:55:22 +00:00