| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
| |
a type when we have a forward declaration. We always have found a
type by basename, but now we also compare the decl context of the
die we are trying to complete with the matches we find from the accelerator
tables to ensure we get the right one.
llvm-svn: 149593
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
due to RTTI worries since llvm and clang don't use RTTI, but I was able to
switch back with no issues as far as I can tell. Once the RTTI issue wasn't
an issue, we were looking for a way to properly track weak pointers to objects
to solve some of the threading issues we have been running into which naturally
led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared
pointer from just a pointer, which is also easily solved using the
std::tr1::enable_shared_from_this class.
The main reason for this move back is so we can start properly having weak
references to objects. Currently a lldb_private::Thread class has a refrence
to its parent lldb_private::Process. This doesn't work well when we now hand
out a SBThread object that contains a shared pointer to a lldb_private::Thread
as this SBThread can be held onto by external clients and if they end up
using one of these objects we can easily crash.
So the next task is to start adopting std::tr1::weak_ptr where ever it makes
sense which we can do with lldb_private::Debugger, lldb_private::Target,
lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and
many more objects now that they are no longer using intrusive ref counted
pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive
pointers).
llvm-svn: 149207
|
| |
|
|
|
|
| |
for when we enable the assisted layout.
llvm-svn: 149167
|
| |
|
|
|
|
|
|
|
| |
will ask ExternalASTSource objects to help laying out a type. This is needed
because the DWARF typically doesn't contain alignement or packing attribute
values, and we need to be able to match up types that the compiler uses
in expressions.
llvm-svn: 149160
|
| |
|
|
|
|
|
|
|
|
| |
be fetched too many times and the DisassemblerLLVM was appending to strings
when the opcode, mnemonic and comment accessors were called multiple times
and if any of the strings were empty.
Also fixed the test suite failures from recent Objective C modifications.
llvm-svn: 148460
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
for each ObjCInterfaceDecl was imposing performance
penalties for Objective-C apps. Instead, we now use
the normal function query mechanisms, which use the
relevant accelerator tables.
This fix also includes some modifications to the
SymbolFile which allow us to find Objective-C methods
and report their Clang Decls correctly.
llvm-svn: 148457
|
| |
|
|
|
|
| |
necessary.
llvm-svn: 148445
|
| |
|
|
|
|
|
|
| |
objective C class names when extracting the class name, selector and
name without category for objective C full class and instance method
names.
llvm-svn: 148435
|
| |
|
|
|
|
|
|
|
|
| |
do things
much smarter by extracting search results more efficiently and by properly obeying the
must_be_implementation bool in the SymbolFileDWARF::FindCompleteObjCDefinitionTypeForDIE()
function.
llvm-svn: 148413
|
| |
|
|
|
|
|
|
| |
Fixed the new __apple_types to be able to accept a DW_TAG_structure_type
forward declaration and then find a DW_TAG_class_type definition, or vice
versa.
llvm-svn: 148097
|
| |
|
|
|
|
|
|
|
| |
from debug info, and those that
are made up from the ObjC runtime symbols. For now the latter contain nothing but the fact that the name
describes an ObjC class, and so are not useful for things like dynamic types.
llvm-svn: 148059
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 148005
|
| |
|
|
|
|
| |
are in the middle of parsing.
llvm-svn: 147914
|
| |
|
|
|
|
|
| |
emit fully qualified names, so now we make sure the DW_TAG values match and
still lookup using the basename.
llvm-svn: 147634
|
| |
|
|
|
|
| |
comma at end of enumerator list
llvm-svn: 147633
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Fixed a crasher that can occur when parsing invalid DWARF.
llvm-svn: 147350
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
which have the dwarf DIE tag (DW_TAG_XXX enum) and TypeFlags for each type.
llvm-svn: 146802
|
| |
|
|
|
|
| |
parse.
llvm-svn: 146473
|
| |
|
|
|
|
| |
it is not required.
llvm-svn: 146418
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
<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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
for now to fix testcases. Once we have a valid use
for the function information (i.e., once properties
returning UnknownAnyTy are allowed, once we read
return type information from the runtime, among
other uses) I will re-enable this.
llvm-svn: 146129
|
| |
|
|
|
|
|
|
|
| |
and CompleteTagDeclarationDefinition() on Objective-C
interfaces populated by SymbolFileSymtab::FindTypes(),
we should mark the interface as forward-declared when
we create it.
llvm-svn: 145825
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
add them to a fast lookup map. lldb_private::Symtab now export the following
public typedefs:
namespace lldb_private {
class Symtab {
typedef std::vector<uint32_t> IndexCollection;
typedef UniqueCStringMap<uint32_t> NameToIndexMap;
};
}
Clients can then find symbols by name and or type and end up with a
Symtab::IndexCollection that is filled with indexes. These indexes can then
be put into a name to index lookup map and control if the mangled and
demangled names get added to the map:
bool add_demangled = true;
bool add_mangled = true;
Symtab::NameToIndexMap name_to_index;
symtab->AppendSymbolNamesToMap (indexes, add_demangled, add_mangled, name_to_index).
This can be repeated as many times as needed to get a lookup table that
you are happy with, and then this can be sorted:
name_to_index.Sort();
Now name lookups can be done using a subset of the symbols you extracted from
the symbol table. This is currently being used to extract objective C types
from object files when there is no debug info in SymbolFileSymtab.
Cleaned up how the objective C types were being vended to be more efficient
and fixed some errors in the regular expression that was being used.
llvm-svn: 145777
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
to use ConstStrings. The const char*s were assumed to
be from ConstStrings before, but since storing a full-on
ConstString is no more expensive than storing a const
char* it makes better sense to enforce uniqueness with
the type checker.
llvm-svn: 145688
|
| |
|
|
|
|
|
|
| |
Objective-C symbols. The methods aren't used yet if
there is a competing definition in the DWARF; I will
resolve that next.
llvm-svn: 145675
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to find Objective-C class types by looking in the
symbol tables for the individual object files.
I did this as follows:
- I added code to SymbolFileSymtab that vends
Clang types for symbols matching the pattern
"_OBJC_CLASS_$_NSMyClassName," making them
appear as Objective-C classes. This only occurs
in modules that do not have debug information,
since otherwise SymbolFileDWARF would be in
charge of looking up types.
- I made a new SymbolVendor subclass for the
Apple Objective-C runtime that is in charge of
making global lookups of Objective-C types. It
currently just sends out type lookup requests to
the appropriate SymbolFiles, but in the future we
will probably extend it to query the runtime more
completely.
I also modified a testcase whose behavior is changed
by the fact that we now actually return an Objective-C
type for __NSCFString.
llvm-svn: 145526
|
| |
|
|
|
|
| |
objective C DWARF emitted by clang.
llvm-svn: 145471
|
| |
|
|
|
|
| |
Find the one true objective C type definition if there is one within a module.
llvm-svn: 145457
|
| |
|
|
|
|
|
| |
Fixed a potential crasher where we weren't checking we got a valid DIE in
a compile unit.
llvm-svn: 145226
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
arguments were quietly masked as the code changed (modified version of a path
from Dawn).
llvm-svn: 145216
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
from them.
llvm-svn: 144440
|
| |
|
|
|
|
|
| |
invalid information. This will help us perfect the tables that are emitted by
clang.
llvm-svn: 144359
|
| |
|
|
|
|
|
|
|
| |
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
|
