The mentioned commit introduced a subtle change in behavior when printing variable names. This
occured when we have a variable, for which we only know the demangled name, because the compiler
has failed to provide one (this typically happens for variables in anonymous namespaces). A
Mangled class which contains only a demangled name considers itself to be invalid (this could
possibly be a bug), but it's GetName() method still returns a valid demangled name. The previous
commit introduced the check for the validity of the class, and if it failed, it would fall back
to printing the bare name (without the namespace prefixes, as the tests were expecting). I revert
this part of the commit and check the validity of the string returned by GetName() instead.
llvm-svn: 241795
Summary:
This commit adds this alternate route only when parsing variable dies
corresponding to global or static variables. The motivation for this is that GCC
does not emit linkage names for functions and variables declared/defined in
anonymous namespaces. Having this alternate route fixes one part of
TestNamespace which fails when the test case is compiled with GCC.
An alternate route to get fully qualified names of functions whose linkage names
are missing will be added with a followup change. With that, the other failing
part of TestNamespace will also be fixed.
Test Plan: dotest.py -C gcc -p TestNamespace
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8569
llvm-svn: 233098
changing it was in r219544 - after living on that for a few
months, I wanted to take another crack at this.
The disassembly-format setting still exists and the old format
can be user specified with a setting like
${current-pc-arrow}${addr-file-or-load}{ <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>}:
This patch was discussed in http://reviews.llvm.org/D7578
<rdar://problem/19726421>
llvm-svn: 229186
This is done by adding a "Variable *" to SymbolContext and allowing SymbolFile::ResolveSymbolContext() so if an address is resolved into a symbol context, we can include the global or static variable for that address.
This means you can now find global variables that are merged globals when doing a "image lookup --verbose --address 0x1230000". Previously we would resolve a symbol and show "_MergedGlobals123 + 1234". But now we can show the global variable name.
The eSymbolContextEverything purposely does not include the new eSymbolContextVariable in its lookup since stack frame code does many lookups and we don't want it triggering the global variable lookups.
<rdar://problem/18945678>
llvm-svn: 226084
output style can be customized. Change the built-in default to be
more similar to gdb's disassembly formatting.
The disassembly-format for a gdb-like output is
${addr-file-or-load} <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>:
The disassembly-format for the lldb style output is
{${function.initial-function}{${module.file.basename}`}{${function.name-without-args}}:\n}{${function.changed}\n{${module.file.basename}`}{${function.name-without-args}}:\n}{${current-pc-arrow} }{${addr-file-or-load}}:
The two backticks in the lldb style formatter triggers the sub-expression evaluation in
CommandInterpreter::PreprocessCommand() so you can't use that one as-is ... changing to
use ' characters instead of ` would work around that.
<rdar://problem/9885398>
llvm-svn: 219544
This is a purely mechanical change explicitly casting any parameters for printf
style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux.
llvm-svn: 205607
pure virtual base class and made StackFrame a subclass of that. As
I started to build on top of that arrangement today, I found that it
wasn't working out like I intended. Instead I'll try sticking with
the single StackFrame class -- there's too much code duplication to
make a more complicated class hierarchy sensible I think.
llvm-svn: 193983
defines a protocol that all subclasses will implement. StackFrame
is currently the only subclass and the methods that Frame vends are
nearly identical to StackFrame's old methods.
Update all callers to use Frame*/Frame& instead of pointers to
StackFrames.
This is almost entirely a mechanical change that touches a lot of
the code base so I'm committing it alone. No new functionality is
added with this patch, no new subclasses of Frame exist yet.
I'll probably need to tweak some of the separation, possibly moving
some of StackFrame's methods up in to Frame, but this is a good
starting point.
<rdar://problem/15314068>
llvm-svn: 193907
A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error.
This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness.
llvm-svn: 186130
Make lldb_private::RegularExpression thread safe everywhere. This was done by removing the m_matches array from the lldb_private::RegularExpression class and putting it into the new lldb_private::RegularExpression::Match class. When executing a regular expression you now have the option to create a lldb_private::RegularExpression::Match object and pass a pointer in if you want to get parenthesized matching. If you don't want any matching, you pass in NULL. The lldb_private::RegularExpression::Match object is initialized with the number of matches you desire. Any matching strings are now extracted from the lldb_private::RegularExpression::Match objects. This makes the regular expression objects thread safe and as a result many more regex objects were turned into static objects that end up using a local lldb_private::RegularExpression::Match object when executing.
llvm-svn: 178702
StackFrame assumes m_sc is additive, but m_sc can lose its target. So now the SymbolContext::Clear() method takes a bool that indicates if the target should be cleared. Modified all existing code to properly set the bool argument.
llvm-svn: 175953
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()
Cleaned up header includes a bit as well.
llvm-svn: 162860
I started work on being able to add symbol files after a debug session
had started with a new "target symfile add" command and quickly ran into
problems with stale Address objects in breakpoint locations that had
lldb_private::Section pointers into modules that had been removed or
replaced. This also let to grabbing stale modules from those sections.
So I needed to thread harded the Address, Section and related objects.
To do this I modified the ModuleChild class to now require a ModuleSP
on initialization so that a weak reference can created. I also changed
all places that were handing out "Section *" to have them hand out SectionSP.
All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild
so all of the find plug-in, static creation function and constructors now
require ModuleSP references instead of Module *.
Address objects now have weak references to their sections which can
safely go stale when a module gets destructed.
This checkin doesn't complete the "target symfile add" command, but it
does get us a lot clioser to being able to do such things without a high
risk of crashing or memory corruption.
llvm-svn: 151336
the lldb_private::StackFrame objects hold onto a weak pointer to the thread
object. The lldb_private::StackFrame objects the the most volatile objects
we have as when we are doing single stepping, frames can often get lost or
thrown away, only to be re-created as another object that still refers to the
same frame. We have another bug tracking that. But we need to be able to
have frames no longer be able to get the thread when they are not part of
a thread anymore, and this is the first step (this fix makes that possible
but doesn't implement it yet).
Also changed lldb_private::ExecutionContextScope to return shared pointers to
all objects in the execution context to further thread harden the internals.
llvm-svn: 150871
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
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
stdarg formats to use __attribute__ format so the compiler can flag
incorrect uses. Fix all incorrect uses. Most of these are innocuous,
a few were resulting in crashes.
llvm-svn: 140185
register names when dumping variable locations and location lists. Also did
some cleanup where "int" types were being used for "lldb::RegisterKind"
values.
llvm-svn: 138988
with the "target modules lookup --address <addr>" command. The variable
ID's, names, types, location for the address, and declaration is
displayed.
This can really help with crash logs since we get, on MacOSX at least,
the registers for the thread that crashed so it is often possible to
figure out some of the variable contents.
llvm-svn: 134886
use lldb_private::Target::ReadMemory(...) to allow constant strings
to be displayed in global variables prior on in between process
execution.
Centralized the variable declaration dumping into:
bool
Variable::DumpDeclaration (Stream *s, bool show_fullpaths, bool show_module);
Fixed an issue if you used "target variable --regex <regex>" where the
variable name would not be displayed, but the regular expression would.
Fixed an issue when viewing global variables through "target variable"
might not display correctly when doing DWARF in object files.
llvm-svn: 134878
Made it so that you can create synthetic children of array
value objects. This is for creating array members when the
array index is out of range. This comes in handy when you have
a structure definition like:
struct Collection
{
uint32_t count;
Item array[0];
};
"array" has 1 item, but many times in practice there are more
items in "item_array".
This allows you to do:
(lldb) target variable g_collection.array[3]
To implement this, the get child at index has been modified
to have a "ignore_array_bounds" boolean that can be set to true.
llvm-svn: 134846
can too. So now the lldb_private::Variable class has support for this.
Variables now have support for having a basename ("i"), and a mangled name
("_ZN12_GLOBAL__N_11iE"), and a demangled name ("(anonymous namespace)::i").
Nowwhen searching for a variable by name, users might enter the fully qualified
name, or just the basename. So new test functions were added to the Variable
and Mangled classes as:
bool NameMatches (const ConstString &name);
bool NameMatches (const RegularExpression ®ex);
I also modified "ClangExpressionDeclMap::FindVariableInScope" to also search
for global variables that are not in the current file scope by first starting
with the current module, then moving on to all modules.
Fixed an issue in the DWARF parser that could cause a varaible to get parsed
more than once. Now, once we have parsed a VariableSP for a DIE, we cache
the result even if a variable wasn't made so we don't do any re-parsing. Some
DW_TAG_variable DIEs don't have locations, or are missing vital info that
stops a debugger from being able to display anything for it, we parse a NULL
variable shared pointer for these DIEs so we don't keep trying to reparse it.
llvm-svn: 119085
artifical members (like the vtable pointer member that shows up in the DWARF).
We were adding this to each class which was making all member variables be off
by a pointer size.
Added a test case so we can track this with "test/forward".
Fixed the type name index in DWARF to include all the types after finding
some types were being omitted due to the DW_AT_specification having the
DW_AT_declaration attribute which was being read into the real type instances
when there were forward declarations in the DWARF, causing the type to be
omitted. We now check to make sure any DW_AT_declaration values are only
respected when parsing types if the attribute is from the current DIE.
After fixing the missing types, we ran into some issues with the expression
parser finding duplicate entries for __va_list_tag since they are built in
types and would result in a "duplicate __va_list_tag definition" error. We
are now just ignoring this name during lookup, but we will need to see if
we can get the name lookup function to not get called in these cases.
Fixed an issue that would cause an assertion where DW_TAG_subroutine_types
that had no children, would not properly make a clang function type of:
"void (*) (void)".
llvm-svn: 116392
Added a "bool show_fullpaths" to many more objects that were
previously always dumping full paths.
Fixed a few places where the DWARF was not indexed when we
we needed it to be when making queries. Also fixed an issue
where the DWARF in .o files wasn't searching all .o files
for the types.
Fixed an issue with the output from "image lookup --type <TYPENAME>"
where the name and byte size might not be resolved and might not
display. We now call the accessors so we end up seeing all of the
type info.
llvm-svn: 113951
to return the correct result.
Fixed "bool Variable::IsInScope (StackFrame *frame)" to return the correct
result when there are no location lists.
Modified the "frame variable" command such that:
- if no arguments are given (dump all frame variables), then we only show
variables that are currently in scope
- if some arguments are given, we show an error if the variable is out of
scope
llvm-svn: 113830
debug map showed that the location lists in the .o files needed some
refactoring in order to work. The case that was failing was where a function
that was in the "__TEXT.__textcoal_nt" in the .o file, and in the
"__TEXT.__text" section in the main executable. This made symbol lookup fail
due to the way we were finding a real address in the debug map which was
by finding the section that the function was in in the .o file and trying to
find this in the main executable. Now the section list supports finding a
linked address in a section or any child sections. After fixing this, we ran
into issue that were due to DWARF and how it represents locations lists.
DWARF makes a list of address ranges and expressions that go along with those
address ranges. The location addresses are expressed in terms of a compile
unit address + offset. This works fine as long as nothing moves around. When
stuff moves around and offsets change between the remapped compile unit base
address and the new function address, then we can run into trouble. To deal
with this, we now store supply a location list slide amount to any location
list expressions that will allow us to make the location list addresses into
zero based offsets from the object that owns the location list (always a
function in our case).
With these fixes we can now re-link random address ranges inside the debugger
for use with our DWARF + debug map, incremental linking, and more.
Another issue that arose when doing the DWARF in the .o files was that GCC
4.2 emits a ".debug_aranges" that only mentions functions that are externally
visible. This makes .debug_aranges useless to us and we now generate a real
address range lookup table in the DWARF parser at the same time as we index
the name tables (that are needed because .debug_pubnames is just as useless).
llvm-gcc doesn't generate a .debug_aranges section, though this could be
fixed, we aren't going to rely upon it.
Renamed a bunch of "UINT_MAX" to "UINT32_MAX".
llvm-svn: 113829
documentation. Symbol now inherits from the symbol
context scope so that the StackID can use a "SymbolContextScope *"
instead of a blockID (which could have been the same as some other
blockID from another symbol file).
Modified the stacks that are created on subsequent stops to reuse
the previous stack frame objects which will allow for some internal
optimization using pointer comparisons during stepping.
llvm-svn: 112495
complex inlined examples.
StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()".
This is because inlined frames will have a PC value that is the same as the
concrete frame that owns the inlined frame, yet the code locations for the
frame can be different. We also need to be able to get the real PC value for
a given frame so that variables evaluate correctly. To get the actual PC
value for a frame you can use:
addr_t pc = frame->GetRegisterContext()->GetPC();
Some issues with the StackFrame stomping on its own symbol context were
resolved which were causing the information to change for a frame when the
stack ID was calculated. Also the StackFrame will now correctly store the
symbol context resolve flags for any extra bits of information that were
looked up (if you ask for a block only and you find one, you will alwasy have
the compile unit and function).
llvm-svn: 111964
to spawn a thread for each process that is being monitored. Previously
LLDB would spawn a single thread that would wait for any child process which
isn't ok to do as a shared library (LLDB.framework on Mac OSX, or lldb.so on
linux). The old single thread used to call wait4() with a pid of -1 which
could cause it to reap child processes that it shouldn't have.
Re-wrote the way Function blocks are handles. Previously I attempted to keep
all blocks in a single memory allocation (in a std::vector). This made the
code somewhat efficient, but hard to work with. I got rid of the old BlockList
class, and went to a straight parent with children relationship. This new
approach will allow for partial parsing of the blocks within a function.
llvm-svn: 111706
Pavel Labath