36da2aa6dc5ad9994b638ed09eb81c44cc05540b |
|
25-Jan-2013 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@173463 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/dwarf.h
|
a1b9a90b7aef446302de9b845dc4f3b0e1473aa7 |
|
13-Nov-2011 |
Greg Clayton <gclayton@apple.com> |
<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. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@144489 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/dwarf.h
|
ccfba727178bb919cdff3365839bed9584df2560 |
|
07-Jul-2010 |
Jason Molenda <jmolenda@apple.com> |
Switch over to using llvm's dwarf constants file. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@107716 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/dwarf.h
|
18728209d1ed915dcc5815a89f4e0c66aff128c7 |
|
15-Jun-2010 |
Jason Molenda <jmolenda@apple.com> |
Add definition for DW_LANG_MIPS_Assembler. This file was originally generated by a script. I don't know if we're still regenerating it or not; will have to check with Greg about how he's handling this now. Should update it for the final DWARF3 and soon-to-be-released DWARF4 constants while I'm at it.. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@106045 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/dwarf.h
|
24943d2ee8bfaa7cf5893e4709143924157a5c1e |
|
08-Jun-2010 |
Chris Lattner <sabre@nondot.org> |
Initial checkin of lldb code from internal Apple repo. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@105619 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/dwarf.h
|