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
types to their full definitions more than we needed to. This caused an assertion
in the DWARF parser to fire -- which is an indication that we are parsing too much.
llvm-svn: 119020
breakpoints on inlined functions by name. This involved fixing the DWARF parser
to correctly back up and parse the concrete function when we find inlined
functions by name, then grabbing any appropriate inlined blocks and returning
symbol contexts with the block filled in. After this was fixed, the breakpoint
by name resolver needed to correctly deal with symbol contexts that had the
inlined block filled in in the symbol contexts.
llvm-svn: 119017
a debug map with DWARF in the .o files due to the attemted shortcut that was
being taken where the global variables were being searched for by looking in
the symbol table. The problem with the symbols in the symbol table is we don't
break apart the symbol names for symbols when they are mangled into basename
and the fully mangled name since this would take a lot of CPU time to chop up
the mangled names and try and find the basenames. The DWARF info typically has
this broken up for us where the basename of the variable is in a the DW_AT_name
attribute, and the mangled name is in the DW_AT_MIPS_linkage_name attribute.
Now we correctly find globals by searching all OSO's for the information so we
can take advantage of this split information.
llvm-svn: 119012
expression. This currently takes waaaayyyyy too much time to evaluate. We will
need to look at the expression parser and find ways to optimize the info we
provide and get this to evaluate quicker. I believe the performance issue is
currently related to us always providing a complete C++ class type when asked
about a C++ class which can cause a lot of information to be pulled since all
classes will be fully created (methods, base classes, members, all their
types). We will need to give the classes back the parser and mark them as
having external sources and get parser (Sema) to query us when it needs more
info. This should bring things up to an acceptable level.
llvm-svn: 118979
cases when getting the clang type:
- need only a forward declaration
- need a clang type that can be used for layout (members and args/return types)
- need a full clang type
This allows us to partially parse the clang types and be as lazy as possible.
The first case is when we just need to declare a type and we will complete it
later. The forward declaration happens only for class/union/structs and enums.
The layout type allows us to resolve the full clang type _except_ if we have
any modifiers on a pointer or reference (both R and L value). In this case
when we are adding members or function args or return types, we only need to
know how the type will be laid out and we can defer completing the pointee
type until we later need it. The last type means we need a full definition for
the clang type.
Did some renaming of some enumerations to get rid of the old "DC" prefix (which
stands for DebugCore which is no longer around).
Modified the clang namespace support to be almost ready to be fed to the
expression parser. I made a new ClangNamespaceDecl class that can carry around
the AST and the namespace decl so we can copy it into the expression AST. I
modified the symbol vendor and symbol file plug-ins to use this new class.
llvm-svn: 118976
needs to use the current pc and current offset in two ways: To
determine which function we are currently executing, and the decide
how much of that function has executed so far. For the former use,
we need to back up the saved pc value by one byte if we're going to
use the correct function's unwind information -- we may be executing
a CALL instruction at the end of a function and the following instruction
belongs to a new function, or we may be looking at unwind information
which only covers the call instruction and not the subsequent instruction.
But when we're talking about deciding which row of an UnwindPlan to
execute, we want to use the actual byte offset in the function, not the
byte offset - 1.
Right now RegisterContextLLDB is tracking both the "real" offset and
an "offset minus one" and different parts of the class have to know
which one to use and they need to be updated/set in tandem. I want
to revisit this at some point.
The second change made in looking up eh_frame information; it was
formerly done by looking for the start address of the function we
are currently executing. But it is possible to have unwind information
for a function which only covers a small section of the function's
address range. In which case looking up by the start pc value may not
find the eh_frame FDE.
The hand-written _sigtramp() unwind info on Mac OS X, which covers
exactly one instruction in the middle of the function, happens to
trigger both of these issues.
I still need to get the UnwindPlan runner to handle arbitrary dwarf
expressions in the FDE but there's a good chance it will be easy to
reuse the DWARFExpression class to do this.
llvm-svn: 118882
logic that supported calling functions with arbitrary
arguments. We use ClangFunction for this, and the
low-level logic is only required to support one or two
pointer arguments.
llvm-svn: 118871
namespaces by name given an optional symbol context. I might end up
dressing up the "clang::NamespaceDecl" into a lldb_private::Namespace
class if we need to do more than is currenlty required of namespaces.
Currently we only need to be able to lookup a namespace by name when
parsing expressions, so I kept it simple for now. The idea here is
even though we are passing around a "clang::NamespaceDecl *", that
we always have it be an opaque pointer (it is forward declared inside
of "lldb/Core/ClangForward.h") and we only use clang::NamespaceDecl
implementations inside of ClangASTContext, or ClangASTType when we need
to extract information from the namespace decl object.
llvm-svn: 118737
comes from by using a virtual function to provide it from the Module's
SymbolVendor by default. This allows the DWARF parser, when being used to
parse DWARF in .o files with a parent DWARF + debug map parser, to get its
type list from the DWARF + debug map parser so when we go and find full
definitions for types (that might come from other .o files), we can use the
type list from the debug map parser. Otherwise we ended up mixing clang types
from one .o file (say a const pointer to a forward declaration "class A") with
the a full type from another .o file. This causes expression parsing, when
copying the clang types from those parsed by the DWARF parser into the
expression AST, to fail -- for good reason. Now all types are created in the
same list.
Also added host support for crash description strings that can be set before
doing a piece of work. On MacOSX, this ties in with CrashReporter support
that allows a string to be dispalyed when the app crashes and allows
LLDB.framework to print a description string in the crash log. Right now this
is hookup up the the CommandInterpreter::HandleCommand() where each command
notes that it is about to be executed, so if we crash while trying to do this
command, we should be able to see the command that caused LLDB to exit. For
all other platforms, this is a nop.
llvm-svn: 118672
Fixed the DWARF plug-in such that when it gets all attributes for a DIE, that
it omits the DW_AT_sibling and DW_AT_declaration when getting attributes
from a DW_AT_abstract_origin or DW_AT_specification DIE.
llvm-svn: 118654
to not get resolved.
Fixed the "void **isa_ptr" variable inside the objective C verifier to start
with a '$' character so we don't go looking for it in our program.
Moved the lookup for "$__lldb_class" into the part that knows we are looking
for internal types that start with a '$'.
llvm-svn: 118488
I only did a tiny bit of testing; in the one case I tried changing the
contents of a radar in the middle of a stack and it was still current in
the live register context so it filtered down to frame 0 and was handed
over to the live register set RegisterContext. I need to test a case
where a register is saved on the stack in memory before I check this
one off.
llvm-svn: 118486
the frame count is requested or each frame is individually requested.
In practice this doesn't seem to help anything because we have
functions like StackFrameList::GetNumFrames() which is going to
request each frame anyway. And classes like ThreadPlanStepRange
and ThreadPlanStepOverRange get the stack depth in their ctor forcing
a full stack walk. But at least UnwindLLDB will delay doing a full
walk if it can.
llvm-svn: 118477
FuncUnwinders object if the eh_frame section was missing
from an objfile. Worked fine on x86_64 but on i386 where
eh_frame is unusual, that resulted in the arch default
UnwindPlan being used all the time instead of picking up
an assembly profile based unwindplan.
llvm-svn: 118467
a pseudo terminal even when the process being attached to.
Fixed a possible crasher in the in:
bool
ClangASTContext::IsAggregateType (clang_type_t clang_type);
It seems that if you pass in a record decl, enum decl, or objc class decl
and ask it if it is an aggregate type, clang will crash.
llvm-svn: 118404
when a function starts and ends, and also the
disassembly for anything that is a client of
ClangExpressionParser after it has been JIT
compiled.
llvm-svn: 118401
the same architecture as a default program, the attach architecture auto
detection would change the architecture to the architecture of the darwin-debug
(which was always x86_64) and hose up your debug session.
llvm-svn: 118399
every external variable reference in the module,
and returning a clean error (instead of letting
LLVM issue a fatal error) if the variable could
not be resolved.
llvm-svn: 118388
and "/private/tmp/a.c". This was done by adding a "mutable bool m_is_resolved;"
member to FileSpec and then modifying the equal operator to check if the
filenames are equal, and if they are, then check the directories. If they are
not equal, then both paths are checked to see if they have been resolved. If
they have been resolved, we resolve the paths in temporary FileSpec objects
and set each of the m_is_resolved bools to try (for lhs and rhs) if the paths
match what is contained in the path. This allows us to do more intelligent
compares without having to resolve all paths found in the debug info (which
can quickly get costly if the files are on remote NFS mounts).
llvm-svn: 118387
where the DWARF is in the .o files so they can track down the actual type for
a forward declaration. This was working before for just DWARF files, but not
for DWARF in .o files where the actual definition was in another .o file.
Modified the main thread name in the driver to be more consistent with the
other LLDB thread names.
llvm-svn: 118383
don't crash if we disable logging when some code already has a copy of the
logger. Prior to this fix, logs were handed out as pointers and if they were
held onto while a log got disabled, then it could cause a crash. Now all logs
are handed out as shared pointers so this problem shouldn't happen anymore.
We are also using our new shared pointers that put the shared pointer count
and the object into the same allocation for a tad better performance.
llvm-svn: 118319
pseudoterminal to pass to the inferior for the inferior's I/O
(to allow direct writing, rather than passing all the I/O around
via packets).
llvm-svn: 118308
that check pointer validity fail to parse. Now
lldb does not crash in that case. Also added
support for checking Objective-C class validity
in the Version 1 runtime as well as Version 2
runtimes with varying levels of available debug
support.
llvm-svn: 118271
fixed them. Added DISALLOW_COPY_AND_ASSIGN to classes that should
not be bitwise copied. Added default initializers for member
variables that weren't being initialized in the ctor. Fixed a few
shadowed local variable mistakes.
llvm-svn: 118240
adding support into lldb_private::Process:
virtual uint32_t
lldb_private::Process::LoadImage (const FileSpec &image_spec,
Error &error);
virtual Error
lldb_private::Process::UnloadImage (uint32_t image_token);
There is a default implementation that should work for both linux and MacOSX.
This ability has also been exported through the SBProcess API:
uint32_t
lldb::SBProcess::LoadImage (lldb::SBFileSpec &image_spec,
lldb::SBError &error);
lldb::SBError
lldb::SBProcess::UnloadImage (uint32_t image_token);
Modified the DynamicLoader plug-in interface to require it to be able to
tell us if it is currently possible to load/unload a shared library:
virtual lldb_private::Error
DynamicLoader::CanLoadImage () = 0;
This way the dynamic loader plug-ins are allows to veto whether we can
currently load a shared library since the dynamic loader might know if it is
currenlty loading/unloading shared libraries. It might also know about the
current host system and know where to check to make sure runtime or malloc
locks are currently being held.
Modified the expression parser to have ClangUserExpression::Evaluate() be
the one that causes the dynamic checkers to be loaded instead of other code
that shouldn't have to worry about it.
llvm-svn: 118227
RegisterContextLLDB holds a reference to the SymbolContext
in the vector of Cursors that UnwindLLDB maintains. Switch
UnwindLLDB to hold a vector of shared pointers of Cursors
so this reference doesn't become invalid.
Correctly falling back from the "fast" UnwindPlan to the
"full" UnwindPlan when additional registers need to be
retrieved.
llvm-svn: 118218
the end of the list. We had an issue in the MacOSX dynamic loader where if
we had shlibs:
1 - a.out
2 - a.dylib
3 - b.dylib
And then a.dylib got unloaded, we would unload b.dylib due to the assumption
that only shared libraries could come off the end of the list. We now properly
search and find which ones get loaded.
Added a new internal logging category for the "lldb" log channel named "dyld".
This should allow all dynamic loaders to use this as a generic log channel so
we can track shared library loads and unloads in the logs without having to
have each plug-in make up its own logging channel.
llvm-svn: 118147
set breakpoints at the different locations where
an exception could be thrown, so that exceptions
thrown by expressions are properly caught.
llvm-svn: 118142
ptrace thread update that was replying to the SIGSTOP was also causing the
process to not really be sigstop'd any more so then the call to ptrace
detach was failing, and when debugserver exited the attached process
was being killed. Now the ptrace thread update does not disturb the sigstop
state of the thread, so the detach works properly.
llvm-svn: 118018
statement. Now when ClangExpressionDeclMap returns
a variable for a name, it pretty-prints that
variable to the log instead of printing a (fairly
useless) NamedDecl pointer.
llvm-svn: 117972
Objective-C member accessibility restrictions.
Ultimately Clang should have a flag that ignores
accessibility for Objective-C like it has one
for C++.
llvm-svn: 117768
than just the entire log channel.
Add checks, where appropriate, to make sure a log channel/category has
not been disabled before attempting to write to it.
llvm-svn: 117715
1. FoundationDisassembleTestCase.test_simple_disasm_with_dsym; and
2. FoundationDisassembleTestCase.test_simple_disasm_with_dwarf
the reason being the test was issuing 'disassemble' command to disassemble the current
frame function when stopped. The 'disassemble' command worked previously but it was a
result of bad option specification.
Fix the disassemble command so that it will require 'disassemble -f' for disassembly of
the current frame function.
llvm-svn: 117688
by type ID (the most common type of type lookup).
Changed the API logging a bit to always show the objects in the OBJECT(POINTER)
format so it will be easy to locate all instances of an object or references
to it when looking at logs.
llvm-svn: 117641
which holds the name of a file whose contents are
prefixed to each expression. For example, if the file
~/lldb.prefix.header contains:
typedef unsigned short my_type;
then you can do this:
(lldb) settings set target.expr-prefix '~/lldb.prefix.header'
(lldb) expr sizeof(my_type)
(unsigned long) $0 = 2
When the variable is changed, the corresponding file
is loaded and its contents are fetched into a string
that is stored along with the target. This string
is then passed to each expression and inserted into
it during parsing, like this:
typedef unsigned short my_type;
void
$__lldb_expr(void *$__lldb_arg)
{
sizeof(my_type);
}
llvm-svn: 117627
version); change include statements to use Python.h in the Python framework
on Mac OS X systems; leave it using regular Python.h on other systems.
Note: I think this *ought* to work properly on Linux systems, but I don't have
a system to test it on...
llvm-svn: 117612
the breakpoint associated with the (filename, line_number) combo when an arrow is pointing to
a source position using Emacs Grand Unified Debugger library to interact with lldb.
The current implmentation is insufficient in that it only asks the breakpoint whether it is
associated with a breakpoint resolver with FileLine type and whether it matches the (filename, line_number)
combo. There are other breakpoint resolver types whose breakpoint locations can potentially
match the (filename, line_number) combo.
The BreakpointResolver, BreakpointResolverName, BreakpointResolverAddress, and BreakpointResolverFileLine
classes have extra static classof methods to support LLVM style type inquiry through isa, cast, and dyn_cast.
The Breakpoint class has an API method bool GetMatchingFileLine(...) which is invoked from CommandObjectBreak.cpp
to implement the "breakpoint clear" command.
llvm-svn: 117562
all of the calls inlined in the header file for better performance.
Fixed the summary for C string types (array of chars (with any combo if
modifiers), and pointers to chars) work in all cases.
Fixed an issue where a forward declaration to a clang type could cause itself
to resolve itself more than once if, during the resolving of the type itself
it caused something to try and resolve itself again. We now remove the clang
type from the forward declaration map in the DWARF parser when we start to
resolve it and avoid this additional call. This should stop any duplicate
members from appearing and throwing all the alignment of structs, unions and
classes.
llvm-svn: 117437
- Try to reduce logging to one line per function call instead of tw
- Put all arguments & their values into log for calls
- Add 'this' parameter information to function call logging, making it show the appropriate
internal pointer (this.obj, this.sp, this.ap...)
- Clean up some return values
- Remove logging of constructors that construct empty objects
- Change '==>' to '=>' for showing result values...
- Fix various minor bugs
- Add some protected 'get' functions to help getting the internal pointers for the 'this' arguments...
llvm-svn: 117417
loaded/parsed. Should add timers to this eventually.
Delay getting a full UnwindPlan if it's possible to unwind with
just a fast UnwindPlan. This keeps us from reading the eh_frame
section unless we hit something built -fomit-frame pointer or we
hit a frame with no symbol (read: no start address) available.
It doesn't look like it is correctly falling back to using the
full UnwindPlan to provide additional registers that the fast
UnwindPlan doesn't supply; e.g. go to the middle of a stack and
ask for r12 and it will show you the value of r12 in frame 0.
That's a bug for tomorrow.
llvm-svn: 117361
gets to be a problem if you have a unbounded stack walk.
Fix the CFA sanity checks. Add one to the arch default UnwindPlan run which was giving
one extra stack frame on the main thread. Fix a couple of logging lines that had their
argument order incorrect.
llvm-svn: 117350
it logs the function calls, their arguments and the return values. This is not
complete or polished, but I am committing it now, at the request of someone who
really wants to use it, even though it's not really done. It currently does not
attempt to log all the functions, just the most important ones. I will be
making further adjustments to the API logging code over the next few days/weeks.
(Suggestions for improvements are welcome).
Update the Python build scripts to re-build the swig C++ file whenever
the python-extensions.swig file is modified.
Correct the help for 'log enable' command (give it the correct number & type of
arguments).
llvm-svn: 117349
prologue profiling.
Change the log print statements to elide the thread number, make
some of them only print when IsLogVerbose().
Add a couple of sanity checks for impossible CFA values so backtraces
don't go too far off into the weeds.
llvm-svn: 117343
Not yet enabled as the default unwinder but there are no known
backtrace problems with the code at this point.
Added 'log enable lldb unwind' to help diagnose backtrace problems;
this output needs a little refining but it's a good first step.
eh_frame information is currently read unconditionally - the code
is structured to allow this to be delayed until it's actually needed.
There is a performance hit when you have to parse the eh_frame
information for any largeish executable/library so it's necessary
to avoid if possible.
It's confusing having both the UnwindPlan::RegisterLocation struct
and the RegisterConextLLDB::RegisterLocation struct, I need to rename
one of them.
The writing of registers isn't done in the RegisterConextLLDB subclass
yet; neither is the running of complex DWARF expressions from eh_frame
(e.g. used for _sigtramp on Mac OS X).
llvm-svn: 117256
Specifically, we fixed handling of the objc_class
built-in type, which allowed us to pass
named Objective-C objects to functions,
call variable list -t on objects safely, etc.
llvm-svn: 117249
"unsigned short." As discussed in the comments,
this is pending a better solution to the problem
of types not in the debug information but readily
available through headers.
llvm-svn: 117247
method results to int. This will only last until we
get accurate type information for Objective-C methods
or some way of making their types inferred by the
parser.
llvm-svn: 117178
So the issue here was that we have lldb_private::FileSpec that by default was
always resolving a path when using the:
FileSpec::FileSpec (const char *path);
and in the:
void FileSpec::SetFile(const char *pathname, bool resolve = true);
This isn't what we want in many many cases. One example is you have "/tmp" on
your file system which is really "/private/tmp". You compile code in that
directory and end up with debug info that mentions "/tmp/file.c". Then you
type:
(lldb) breakpoint set --file file.c --line 5
If your current working directory is "/tmp", then "file.c" would be turned
into "/private/tmp/file.c" which won't match anything in the debug info.
Also, it should have been just a FileSpec with no directory and a filename
of "file.c" which could (and should) potentially match any instances of "file.c"
in the debug info.
So I removed the constructor that just takes a path:
FileSpec::FileSpec (const char *path); // REMOVED
You must now use the other constructor that has a "bool resolve" parameter that you must always supply:
FileSpec::FileSpec (const char *path, bool resolve);
I also removed the default parameter to SetFile():
void FileSpec::SetFile(const char *pathname, bool resolve);
And fixed all of the code to use the right settings.
llvm-svn: 116944
if passed in a NULL new_value and the operation intended is eVarSetOperationAssign.
This fixed a bug where in TestSettings.py:
# Set the run-args and the env-vars.
self.runCmd('settings set target.process.run-args A B C')
self.runCmd('settings set target.process.env-vars ["MY_ENV_VAR"]=YES')
# And add hooks to restore the settings during tearDown().
self.addTearDownHook(
lambda: self.runCmd("settings set -r target.process.run-args"))
self.addTearDownHook(
lambda: self.runCmd("settings set -r target.process.env-vars"))
"settings set -r target.process.env-vars" was not restoring the original env-vars
setting.
llvm-svn: 116895
optionally specify the tty you want to use if you want to use an existing
terminal window by giving a partial or full path name:
(lldb) process launch --tty=ttys002
This would find the terminal window (or tab on MacOSX) that has ttys002 in its
tty path and use it. If it isn't found, it will use a new terminal window.
llvm-svn: 116878
We now spawn a thread to accept a unix socket connection from the inferior
when it spawns in the terminal, then we launch the process, then we get
the pid back through the unix socket, and then wait for it to SIGSTOP.
darwin-debug now clears the terminal screen and prints out the program and
arguments that are about to be launched.
llvm-svn: 116841
sockets so the driver doesn't just crash.
Added support for connecting to named sockets (unix IPC sockets) in
ConnectionFileDescriptor.
Modified the Host::LaunchInNewTerminal() for MacOSX to return the process
ID of the inferior process instead of the process ID of the Terminal.app. This
was done by modifying the "darwin-debug" executable to connect to lldb through
a named unix socket which is passed down as an argument. This allows a quick
handshake between "lldb" and "darwin-debug" so we can get the process ID
of the inferior and then attach by process ID and avoid attaching to the
inferior by process name since there could be more than one process with
that name. This still has possible race conditions, those will be fixed
in the near future. This fixes the SIGPIPE issues that were sometimes being
seen when task_for_pid was failing.
llvm-svn: 116792
but something is still killing our inferior.
Fixed an issue with darwin-debug where it wasn't passing all needed arguments
to the inferior.
Fixed a race condition with the attach to named process code.
llvm-svn: 116697
Greg Clayton