ModuleList so they don't show up in the images. Breakpoint locations that are
in shared libraries that get unloaded will persist though so that if you
have plug-ins that load/unload and you have a breakpoint set on functions
in the plug-ins, the hit counts will persist between loads/unloads.
llvm-svn: 121069
Mark NSArray_expr() and NSString_expr() as currently failing. Both are called
from dsym and dwarf builds. So that makes the num of expected failures equal 4.
----------------------------------------------------------------------
Ran 6 tests in 19.856s
OK (expected failures=4)
llvm-svn: 121068
wrongly as the target of a pointer rather than the
SEL pointer itself. This caused incorrect behavior
when dealing with Objective-C selector variables.
llvm-svn: 121048
o test_many_expr_commands()
o test_expr_commands_can_handle_quotes()
Mark test_expr_commands_can_handle_quotes()
as @expectedFailure:
# rdar://problem/8686536
# CommandInterpreter::HandleCommand is stripping \'s from input for WantsRawCommand commands
llvm-svn: 121019
do. Closing on EOF is an option that can be set on the
lldb_private::Communication or the lldb::SBCommunication objects after they
are created. Of course the EOF support isn't hooked up, so they don't do
anything at the moment, but they are left in so when the code is fixed, it
will be easy to get working again.
llvm-svn: 120885
was done as an settings variable in the process for now. We will eventually
move all environment stuff over to the target, but we will leave it with the
process for now. The default setting is for a process to inherit the host
environment. This can be disabled by setting the "inherit-env" setting to
false in the process.
llvm-svn: 120862
inferior to be launched without setting up terminal stdin/stdout for it
(leaving the lldb command line accessible while the program is executing).
Also add a user settings variable, 'target.process.disable-stdio' to allow
the user to set this globally rather than having to use the command option
each time the process is launched.
llvm-svn: 120825
an error saying the resume timed out. Previously the thread that was trying
to resume the process would eventually call ProcessGDBRemote::DoResume() which
would broadcast an event over to the async GDB remote thread which would sent the
continue packet to the remote gdb server. Right after this was sent, it would
set a predicate boolean value (protected by a mutex and condition) and then the
thread that issued the ProcessGDBRemote::DoResume() would then wait for that
condition variable to be set. If the async gdb thread was too quick though, the
predicate boolean value could have been set to true and back to false by the
time the thread that issued the ProcessGDBRemote::DoResume() checks the boolean
value. So we can't use the predicate value as a handshake. I have changed the code
over to using a Event by having the GDB remote communication object post an
event:
GDBRemoteCommunication::eBroadcastBitRunPacketSent
This allows reliable handshaking between the two threads and avoids the erroneous
ProcessGDBRemote::DoResume() errors.
Added a host backtrace service to allow in process backtraces when trying to track
down tricky issues. I need to see if LLVM has any backtracing abilities abstracted
in it already, and if so, use that, but I needed something ASAP for the current issue
I was working on. The static function is:
void
Host::Backtrace (Stream &strm, uint32_t max_frames);
And it will backtrace at most "max_frames" frames for the current thread and can be
used with any of the Stream subclasses for logging.
llvm-svn: 120793
so that it is not referring to potentially stale
state during IR execution.
This was done by introducing modular state (like
ClangExpressionVariable) where groups of state
variables have well-defined lifetimes:
- m_parser_vars are specific to parsing, and only
exist between calls to WillParse() and DidParse().
- m_struct_vars survive for the entire execution
of the ClangExpressionDeclMap because they
provide the template for a materialized set of
expression variables.
- m_material_vars are specific to a single
instance of materialization, and only exist
between calls to Materialize() and
Dematerialize().
I also removed unnecessary references to long-
lived state that really didn't need to be referred
to at all, and also introduced several assert()s
that helped me diagnose a few bugs (fixed too).
llvm-svn: 120778
Johnny Chen