summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/SymbolFile/DWARF
Commit message (Collapse)AuthorAgeFilesLines
...
* <rdar://problem/10681814>Greg Clayton2012-01-126-84/+222
| | | | | | | | | | Fix DWARF parsing issue we can run into when using llvm-gcc based dSYM files. Also fix the parsing of objective C built-in types (Class, id and SEL) so they don't parse more information that is not needed due to the way they are represented in DWARF. llvm-svn: 148016
* Don't dereference the oso_dwarf without checking for NULL.Jim Ingham2012-01-121-2/+2
| | | | llvm-svn: 148005
* Don't assert but report & return a NULL type if we end up parsing a type we ↵Jim Ingham2012-01-111-2/+12
| | | | | | are in the middle of parsing. llvm-svn: 147914
* We finalized on the new .apple_types accelerator table format where we don'tGreg Clayton2012-01-065-7/+48
| | | | | | | emit fully qualified names, so now we make sure the DW_TAG values match and still lookup using the basename. llvm-svn: 147634
* http://llvm.org/bugs/show_bug.cgi?id=11715Johnny Chen2012-01-061-1/+1
| | | | | | comma at end of enumerator list llvm-svn: 147633
* Added code in the Host layer that can report system log messagesGreg Clayton2012-01-054-163/+175
| | | | | | | | | | | | so that we don't have "fprintf (stderr, ...)" calls sprinkled everywhere. Changed all needed locations over to using this. For non-darwin, we log to stderr only. On darwin, we log to stderr _and_ to ASL (Apple System Log facility). This will allow GUI apps to have a place for these error and warning messages to go, and also allows the command line apps to log directly to the terminal. llvm-svn: 147596
* <rdar://problem/10507811>Greg Clayton2012-01-043-26/+51
| | | | | | | | | | Be better at detecting when DWARF changes and handle this more gracefully than asserting and exiting. Also fixed up a bunch of system calls that weren't properly checking for EINTR. llvm-svn: 147559
* <rdar://problem/10551280>Greg Clayton2011-12-292-2/+17
| | | | | | Fixed a crasher that can occur when parsing invalid DWARF. llvm-svn: 147350
* <rdar://problem/10568905>Greg Clayton2011-12-291-41/+110
| | | | | | | | | | | | | | | | | | | | | | | | | Fixed an issue where our new accelerator tables could cause a crash when we got a full 32 bit hash match, yet a C string mismatch. We had a member variable in DWARFMappedHash::Prologue named "min_hash_data_byte_size" the would compute the byte size of HashData so we could skip hash data efficiently. It started out with a byte size value of 4. When we read the table in from disk, we would clear the atom array and read it from disk, and the byte size would still be set to 4. We would then, as we read each atom from disk, increment this count. So the byte size of the HashData was off, which means when we get a lookup whose 32 bit hash does matches, but the C string does NOT match (which is very very rare), then we try and skip the data for that hash and we would add an incorrect offset and get off in our parsing of the hash data and cause this crash. To fix this I added a few safeguards: 1 - I now correctly clear the hash data size when we reset the atom array using the new DWARFMappedHash::Prologue::ClearAtoms() function. 2 - I now correctly always let the AppendAtom() calculate the byte size of the hash (before we were doing things manually some times, which was correct, but not good) 3 - I also track if the size of each HashData is a fixed byte size or not, and "do the right thing" when we need to skip the data. 4 - If we do get off in the weeds, then I make sure to return an error and stop any further parsing from happening. llvm-svn: 147334
* Modified LLDB to be able to handle our updated __apple_types accelerator tablesGreg Clayton2011-12-171-47/+39
| | | | | | which have the dwarf DIE tag (DW_TAG_XXX enum) and TypeFlags for each type. llvm-svn: 146802
* Use forward declarations more of the time to save on things that we need to Greg Clayton2011-12-131-2/+2
| | | | | | parse. llvm-svn: 146473
* Use forward types where possible to avoid having to parse extra DWARF whenGreg Clayton2011-12-121-8/+10
| | | | | | it is not required. llvm-svn: 146418
* <rdar://problem/9958446>Greg Clayton2011-12-101-17/+0
| | | | | | | | | | | | | | <rdar://problem/10561406> Stopped the SymbolFileDWARF::FindFunctions (...) from always calculating the line table entry for all functions that were found. This can slow down the expression parser if it ends up finding a bunch of matches. Fixed the places that were relying on the line table entry being filled in. Discovered a recursive stack blowout that happened when "main" didn't have line info for it and there was no line information for "main" llvm-svn: 146330
* <rdar://problem/10559329>Greg Clayton2011-12-102-124/+57
| | | | | | | | | An assertion was firing when parsing types due to trying to complete parent class decl contenxt types too often. Also, relax where "dsymutil" binary can come from in the Makefile.rules. llvm-svn: 146310
* Tested a theory on the where when we lookup things in the accelerator tablesGreg Clayton2011-12-094-4/+168
| | | | | | | | | | | | | | that if we prefer the current compile unit, followed by any compile units that already had their DIEs parsed, followed by the rest of the matches, that we might save some memory. This turned out not to help much. The code is commented out, but I want to check it in so I don't lose the code in case it could help later. Added the ability to efficiently find the objective C class implementation when using the new .apple_types acclerator tables with the type flags. If the type flags are not available, we default back to what we were doing before. llvm-svn: 146250
* If the expression parser is unable to complete a TagDeclSean Callanan2011-12-081-16/+19
| | | | | | | | | | | | | | in the context in which it was originally found, the expression parser now goes hunting for it in all modules (in the appropriate namespace, if applicable). This means that forward-declared types that exist in another shared library will now be resolved correctly. Added a test case to cover this. The test case also tests "frame variable," which does not have this functionality yet. llvm-svn: 146204
* Fixed an issue where we are asking to get the decl context for a functionGreg Clayton2011-12-082-20/+43
| | | | | | | | that is in a class from the expression parser, and it was causing an assertion. There is now a function that will correctly resolve a type even if it is in a class. llvm-svn: 146141
* Added a new class called lldb_private::SymbolFileType which is designed toGreg Clayton2011-12-084-95/+394
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | take a SymbolFile reference and a lldb::user_id_t and be used in objects which represent things in debug symbols that have types where we don't need to know the true type yet, such as in lldb_private::Variable objects. This allows us to defer resolving the type until something is used. More specifically this allows us to get 1000 local variables from the current function, and if the user types "frame variable argc", we end up _only_ resolving the type for "argc" and not for the 999 other local variables. We can expand the use of this as needed in the future. Modified the DWARFMappedHash class to be able to read the HashData that has more than just the DIE offset. It currently will read the atoms in the header definition and read the data correctly. Currently only the DIE offset and type flags are supported. This is needed for adding type flags to the .apple_types hash accelerator tables. Fixed a assertion crash that would happen if we have a variable that had a DW_AT_const_value instead of a location where "location.LocationContains_DW_OP_addr()" would end up asserting when it tried to parse the variable location as a DWARF opcode list. Decreased the amount of memory that LLDB would use when evaluating an expression by 3x - 4x for clang. There was a place in the namespace lookup code that was parsing all namespaces with a certain name in a DWARF file instead of stopping when it found the first match. This was causing all of the compile units with a matching namespace to get parsed into memory and causing unnecessary memory bloat. Improved "Target::EvaluateExpression(...)" to not try and find a variable when the expression contains characters that would certainly cause an expression to need to be evaluated by the debugger. llvm-svn: 146130
* Added code to make sure we don't recursively try to find an objective CGreg Clayton2011-12-034-14/+216
| | | | | | | | | | | class. The thing with Objective C classes is the debug info might have a definition that isn't just a forward decl, but it is incomplete. So we need to look and see if we can find the complete definition and avoid recursing a lot due to the fact that our accelerator tables will have many versions of the type, but only one complete one. We might not also have the complete type and we need to deal with this correctly. llvm-svn: 145759
* Testcase fixes with the new symbol lookup code forSean Callanan2011-12-034-4/+4
| | | | | | | | | | | | Objective-C, making symbol lookups for various raw Objective-C symbols work correctly. The IR interpreter makes these lookups because Clang has emitted raw symbol references for ivars and classes. Also improved performance in SymbolFiles, caching the result of asking for SymbolFile abilities. llvm-svn: 145758
* <rdar://problem/10522194>Greg Clayton2011-12-031-19/+47
| | | | | | | | | | | | | | | Fixed an issue where if we have the DWARF equivalent of: struct foo; class foo { ... }; Or vice versa, we wouldn't be able to find the complete type. Since many compilers allow forward declarations to have struct and definitions to have class, we need to be able to deal with both cases. This commit fixes this in the DWARF parser. llvm-svn: 145733
* Add a work around to deal with incorrect forward class definitions in Greg Clayton2011-11-301-0/+18
| | | | | | objective C DWARF emitted by clang. llvm-svn: 145471
* <rdar://problem/10500242>Greg Clayton2011-11-291-14/+27
| | | | | | Find the one true objective C type definition if there is one within a module. llvm-svn: 145457
* <rdar://problem/10413589>Greg Clayton2011-11-281-19/+22
| | | | | | | Fixed a potential crasher where we weren't checking we got a valid DIE in a compile unit. llvm-svn: 145226
* CommandObjectProcess was recently changed to automatically use the platformGreg Clayton2011-11-285-99/+257
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to launch a process for debugging. Since this isn't supported on all platforms, we need to do what we used to do if this isn't supported. I added: bool Platform::CanDebugProcess (); This will get checked before trying to launch a process for debugging and then fall back to launching the process through the current host debugger. This should solve the issue for linux and keep the platform code clean. Centralized logging code for logging errors, warnings and logs when reporting things for modules or symbol files. Both lldb_private::Module and lldb_private::SymbolFile now have the following member functions: void LogMessage (Log *log, const char *format, ...); void ReportWarning (const char *format, ...); void ReportError (const char *format, ...); These will all output the module name and object (if any) such as: "error: lldb.so ...." "warning: my_archive.a(foo.o) ...." This will keep the output consistent and stop a lot of logging calls from having to try and output all of the information that uniquely identifies a module or symbol file. Many places in the code were grabbing the path to the object file manually and if the module represented a .o file in an archive, we would see log messages like: error: foo.a - some error happened llvm-svn: 145219
* Fixed an issue in the DWARFLocationList::Dump() function where default Greg Clayton2011-11-281-1/+5
| | | | | | | arguments were quietly masked as the code changed (modified version of a path from Dawn). llvm-svn: 145216
* Shrink-to-fit our std::vector<DWARFDebugInfoEntry> collections and save 20%Greg Clayton2011-11-223-8/+16
| | | | | | | to 30% of memory. The size doubling was killing us and we ended up with up to just under 50% of empty capacity. Cleaning this up saves us a ton of memory. llvm-svn: 145086
* Further performance improvements in the DWARF parser:Greg Clayton2011-11-194-137/+134
| | | | | | | | | 1 - the DIE collections no longer have the NULL tags which saves up to 25% of the memory on typical C++ code 2 - faster parsing by not having to run the SetDIERelations() function anymore it is done when parsing the DWARF very efficiently. llvm-svn: 144983
* Looking at our memory usage with Instruments when debugging a large applicationGreg Clayton2011-11-183-285/+131
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | we say that the vectors of DWARFDebugInfoEntry objects were the highest on the the list. With these changes we cut our memory usage by 40%!!! I did this by reducing the size of the DWARFDebugInfoEntry from a previous: uint32_t offset uint32_t parent_idx uint32_t sibling_idx Abbrev * abbrev_ptr which was 20 bytes, but rounded up to 24 bytes due to alignment. Now we have: uint32_t offset uint32_t parent_idx uint32_t sibling_idx uint32_t abbr_idx:15, // 32767 possible abbreviation codes has_children:1, // 0 = no children, 1 = has children tag:16; // DW_TAG_XXX value This gets us down to 16 bytes per DIE. I tested some VERY large DWARF files (900MB) and found there were only ~700 unique abbreviations, so 32767 should be enough for any sane compiler. If it isn't there are built in assertions that will fire off and tell us. llvm-svn: 144975
* <rdar://problem/10338439>Greg Clayton2011-11-132-95/+114
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add code that reads the APPLE_property debug info, and makes up properties ↵Jim Ingham2011-11-121-1/+31
| | | | | | from them. llvm-svn: 144440
* Added report errors for when the .apple_XXXX hashed name table lookups containGreg Clayton2011-11-111-55/+152
| | | | | | | invalid information. This will help us perfect the tables that are emitted by clang. llvm-svn: 144359
* Made the Host::SetCrashDescription(const char *) function copy the incomingGreg Clayton2011-11-101-0/+2
| | | | | | | | | string to avoid possible later crashes. Modified the locations that do set the crash description to NULL out the string when they are done doing their tasks. llvm-svn: 144297
* <rdar://problem/10338439>Greg Clayton2011-11-101-0/+2
| | | | | | | | Fixed an issue where if you had an initialized global variable, we would not link it up correctly in the debug info if the .o file had the symbols as UNDF + EXT (undefined external). We now properly link the globals. llvm-svn: 144259
* Sometimes the debug information includes artifically-Sean Callanan2011-11-021-3/+5
| | | | | | | | | | | | | generated special member functions (constructors, destructors, etc.) for classes that don't really have them. We needed to mark these as artificial to reflect the debug information; this bug does that for constructors and destructors. The "etc." case (certain assignment operators, mostly) remains to be fixed. llvm-svn: 143526
* Added the capability (turned off for now) to mark aSean Callanan2011-11-011-1/+4
| | | | | | | | | | | | | | | | method as __attribute__ ((used)) when adding it to a class. This functionality is useful when stopped in anonymous namespaces: expressions attached to classes in anonymous namespaces are typically elided by Clang's CodeGen because they have no namespaces are intended not to be externally visible. __attribute__ ((used)) forces CodeGen to emit the function. Right now, __attribute__ ((used)) causes the JIT not to emit the function, so we're not enabling it until we fix that. llvm-svn: 143469
* Fixed some warnings after enabling some stricter warnings in the Xcode projectGreg Clayton2011-10-311-11/+34
| | | | | | | | | settings. Also fixed an issue where we weren't creating anonymous namepaces correctly: <rdar://problem/10371295> llvm-svn: 143403
* warnings: Fix several uses of trailing comma on enumeration extensions.Daniel Dunbar2011-10-311-1/+1
| | | | llvm-svn: 143380
* Added support for the C++Ox "nullptr_t" type.Greg Clayton2011-10-282-0/+12
| | | | llvm-svn: 143225
* Added support for the new ".apple_objc" accelerator tables. These tables areGreg Clayton2011-10-272-8/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in the same hashed format as the ".apple_names", but they map objective C class names to all of the methods and class functions. We need to do this because in the DWARF the methods for Objective C are never contained in the class definition, they are scattered about at the translation unit level and they don't even have attributes that say the are contained within the class itself. Added 3 new formats which can be used to display data: eFormatAddressInfo eFormatHexFloat eFormatInstruction eFormatAddressInfo describes an address such as function+offset and file+line, or symbol + offset, or constant data (c string, 2, 4, 8, or 16 byte constants). The format character for this is "A", the long format is "address". eFormatHexFloat will print out the hex float format that compilers tend to use. The format character for this is "X", the long format is "hex float". eFormatInstruction will print out disassembly with bytes and it will use the current target's architecture. The format character for this is "i" (which used to be being used for the integer format, but the integer format also has "d", so we gave the "i" format to disassembly), the long format is "instruction". Mate the lldb::FormatterChoiceCriterion enumeration private as it should have been from the start. It is very specialized and doesn't belong in the public API. llvm-svn: 143114
* Fixed an issue where a class that resides inside another class wasn't gettingGreg Clayton2011-10-262-2/+16
| | | | | | | an access specifier set on it, causing an assertion to fire when building with a Debug+Asserts build of clang. llvm-svn: 143010
* <rdar://problem/10335756>Greg Clayton2011-10-251-1/+20
| | | | | | | | Fixed an issue where bad DWARF from clang would get recycled from DWARF back into types and cause clang to assert and die, killing the lldb binary, when it tried to used the type in an expression. llvm-svn: 142897
* Added template support when parsing DWARF into types. We can now use STLGreg Clayton2011-10-222-18/+190
| | | | | | classes in the expression parser. llvm-svn: 142717
* Fixed some issues where we might not have one of the new apple acceleratorGreg Clayton2011-10-204-676/+159
| | | | | | | | | | | tables (like the .apple_namespaces) and it would cause us to index DWARF that didn't need to be indexed. Updated the MappedHash.h (generic Apple accelerator table) and the DWARF specific one (HashedNameToDIE.h) to be up to date with the latest and greatest hash table format. llvm-svn: 142627
* Moved lldb::user_id_t values to be 64 bit. This was going to be needed forGreg Clayton2011-10-194-89/+169
| | | | | | | | | | | process IDs, and thread IDs, but was mainly needed for for the UserID's for Types so that DWARF with debug map can work flawlessly. With DWARF in .o files the type ID was the DIE offset in the DWARF for the .o file which is not unique across all .o files, so now the SymbolFileDWARFDebugMap class will make the .o file index part (the high 32 bits) of the unique type identifier so it can uniquely identify the types. llvm-svn: 142534
* Changed lldb_private::Type over to use the intrusive ref counted pointersGreg Clayton2011-10-182-46/+30
| | | | | | | | | | | so we don't have to lookup types in a type list by ID. Changed the DWARF parser to remove the "can externally complete myself" bits from the type when we are in the process of completing the type itself to avoid an onslaught of external visible decl requests from the clang::ExternalASTSource. llvm-svn: 142461
* Add function decls to their parent decl context.Greg Clayton2011-10-141-1/+2
| | | | llvm-svn: 142011
* Make sure we create only unique one namespace per AST when parsing the DWARF.Greg Clayton2011-10-142-24/+40
| | | | llvm-svn: 142005
* Modified the DWARF parser to take care of a 1 clang::DeclContext to manyGreg Clayton2011-10-132-47/+60
| | | | | | DIEs. Prior to this fix, there was a 1 to 1 mapping. llvm-svn: 141917
* Fixed a case where we might end up trying to parse a type in the DWARF ↵Greg Clayton2011-10-131-22/+59
| | | | | | parser for a method whose class isn't currently in the process of completing itself. Currently, methods of a class, must be parsed when the class type that contains the method is asked to complete itself through the clang::ExternalASTSource virtual functions. Now we "do the right thing" by checking if the class is being defined, and if so we parse it, else we tell the class to complete itself so everything happens correctly. llvm-svn: 141908
OpenPOWER on IntegriCloud