section for x86_64 and i386 targets on Darwin systems. Currently only the
compact unwind encoding for normal frame-using functions is supported but it
will be easy handle frameless functions when I have a bit more free time to
test it. The LSDA and personality routines for functions are also retrieved
correctly for functions from the compact unwind section.
This new code is very fresh -- it passes the lldb testsuite and I've done
by-hand inspection of many functions and am getting correct behavior for all
of them. There may need to be some bug fixing over the next couple weeks as
I exercise and test it further. But I think it's fine right now so I'm
committing it.
<rdar://problem/13220837>
llvm-svn: 223625
in the "dummy-target". The dummy target breakpoints prime all future
targets. Breakpoints set before any target is created (e.g. breakpoints
in ~/.lldbinit) automatically get set in the dummy target. You can also
list, add & delete breakpoints from the dummy target using the "-D" flag,
which is supported by most of the breakpoint commands.
This removes a long-standing wart in lldb...
<rdar://problem/10881487>
llvm-svn: 223565
encounter clang::ExternalASTSources that are not instances
of ClangExternalASTSourceCommon. We used to blithely
assume that all are, and so we could use static_cast<>.
That's no longer the case, so we have to have these AST
sources register themselves.
llvm-svn: 223560
type format info
type summary info
type synthetic info
These commands all take an expression, evaluate it, and show which of the respective formatter (if any) applies to the result of the expression
Fixes rdar://12059317
llvm-svn: 223511
Summary: If lldb is not built, dotest.py throws an exception because we are using an unset variable.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6516
llvm-svn: 223446
support to LLDB. It includes the following:
- Changed DeclVendor to TypeVendor.
- Made the ObjCLanguageRuntime provide a DeclVendor
rather than a TypeVendor.
- Changed the consumers of TypeVendors to use
DeclVendors instead.
- Provided a few convenience functions on
ClangASTContext to make that easier.
llvm-svn: 223433
like tgmath.h and stdarg.h into the LLDB installation,
and then finding them through the Host infrastructure.
Also add a script to actually do this on Mac OS X.
llvm-svn: 223430
There is at least one test that hangs on the Linux debian buildbot.
When that test hangs, the buildbot kills dosep which loses all test
results. This change kills just the hung test and should let us see
which test is hanging. This is useful for that test and any others
in the future which start hanging.
llvm-svn: 223423
This reverts commit 4a5ad2c077166cc3d6e7ab4cc6e3dcbbe922af86.
Windows doesn't support select() for pipe objects, and this also fails
to compile on Windows. Reverting this until we can get it sorted out
to keep the windows build working.
llvm-svn: 223392
lldb::TypeSP
SymbolFileDWARF::FindDefinitionTypeForDIE (
DWARFCompileUnit* dwarf_cu,
const DWARFDebugInfoEntry *die,
const lldb_private::ConstString &type_name);
This function isn't used as it has been replaced by:
lldb::TypeSP
SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext (
const DWARFDeclContext &die_decl_ctx);
I am about to change the way we resolve C/C++ class/struct/union types and want to clean up SymbolFileDWARF before I start.
llvm-svn: 223376
It was observed that we dont need to set stdin to unbuffered and setting console
to non-canonical mode.
Patch originally came from "Ilia K <ki.stfu@gmail.com>"
llvm-svn: 223353
This is a temporary workaround to get deferred breakpoint
resolution working until Bug 21720 is addressed. Even with this
workaround, it will only resolve deferred breakpoints in the
executable module, and not in a shared library.
llvm-svn: 223273
Previously if we got a DoDestroy while stopped at a breakpoint, we
would detach and then say the process had exited. This is completely
wrong, as it resulted in the python script incorrectly assuming that
the process had actually exited and trying to delete the image, when
in fact it had done no such thing.
The fix employed here is that when we get a DoDestroy, we do 3 steps:
1) initiate a termination sequence on the process
2) If we were stopped handling an exception of any kind, mask it and
let the program resume, causing the program to see the termination
request and exit on its own.
3) Let the program exit normally, and close all of our handles before
returning control back to DoDestroy.
This fixes Bug 21722 and Bug 21723.
llvm-svn: 223272
There were 2 different patches in discussion. One using ioctl
and other using select. We decided to use the ioctl but committed
code also have some changes which were only needed for 'select'.
This patch removes them.
llvm-svn: 223227
preserved) in the ABI.
Realistically lldb isn't able to track register saves of any of
the neon regs right now so we should probably mark all of the
regs as unavailable when you're not on stack frame 0...
<rdar://problem/19115127>
llvm-svn: 223174
format for the not-current-stack-frame. This was causing
test/functionalities/inferior-assert to fail.
Also document the new additions to the format specifications used
in the disassembly-format changes to formats.html.
<rdar://problem/19102757>
llvm-svn: 223096
Clang generates DWARF debug info with section names longer
than 8 characters. This is only supported by an extension
to PE/COFF which the MSVC linker doesn't implement. So
trying to link DWARF-enabled object files with MSVC will
lead to corrupt debug information in the executable.
llvm-svn: 223088
% lldb /bin/nonono
(lldb) target create "/bin/nonono"
error: unable to find executable for '/usr/bin/nonono'
<deadlock>
The problem was the initial commands 'target create "/bin/nonono"' were put into a pipe and the command interpreter was being run with:
void
CommandInterpreter::RunCommandInterpreter(bool auto_handle_events,
bool spawn_thread,
CommandInterpreterRunOptions &options)
{
// Always re-create the command intepreter when we run it in case
// any file handles have changed.
bool force_create = true;
m_debugger.PushIOHandler(GetIOHandler(force_create, &options));
m_stopped_for_crash = false;
if (auto_handle_events)
m_debugger.StartEventHandlerThread();
if (spawn_thread)
{
m_debugger.StartIOHandlerThread();
}
else
{
m_debugger.ExecuteIOHanders();
if (auto_handle_events)
m_debugger.StopEventHandlerThread();
}
}
If "auto_handle_events" was set to true and "spawn_thread" was false, we would execute:
m_debugger.StartEventHandlerThread();
m_debugger.ExecuteIOHanders();
m_debugger.StopEventHandlerThread();
The problem was there was no synchonization in Debugger::StartEventHandlerThread() to ensure the event handler was listening to events and the the call to "m_debugger.StopEventHandlerThread()" would do:
void
Debugger::StopEventHandlerThread()
{
if (m_event_handler_thread.IsJoinable())
{
GetCommandInterpreter().BroadcastEvent(CommandInterpreter::eBroadcastBitQuitCommandReceived);
m_event_handler_thread.Join(nullptr);
}
}
The problem was that the event thread might not be listening for the CommandInterpreter::eBroadcastBitQuitCommandReceived event yet.
The solution is to make sure the Debugger::DefaultEventHandler() is listening to events before we return from Debugger::StartEventHandlerThread(). Once we have this synchonization we remove the race condition.
This fixes radar:
<rdar://problem/19041192>
llvm-svn: 223083
(lldb) b /break here/
This will set a source level regular expression breakpoint on any text between the first '/' and the last '/'. The equivalent command will be:
(lldb) breakpoint set --source-pattern-regexp 'break here'
llvm-svn: 223082
DecodeHexU8 returns a decoded hex character pair, returns -1 if a
valid hex pair is not available.
GetHexBytesAvail decodes all available hex pairs.
llvm-svn: 223081
for x86_64. i386, arm, arm64 aren't handled yet but those are minor
variations on this format.
This commit also adds code to read the symbol table out of the
binary and read the LC_FUNCTION_STARTS to augment the symbol table
with the start addresses of all the functions - and print the
function names when showing the unwind info.
llvm-svn: 222951
UNWIND_X86_64_MODE_STACK_IND mode is almost correct; extra stack
space allocated before the reg saves isn't handled right. Still a
little wobbily on the file addresses of functions. Finally understand
how the 6 registers that may be saved are ordered in just 10 its
of space -- the Lehmer code for the registers is derived and then
the sequence is encoded in a variable base number. Added some
comments with references to what the code is doing so it'll be
easier for others to track down.
llvm-svn: 222884
summary of changes:
Cleanup: Use "line_number" API instead of hardcoded source lines
Combine child.sendline with previous child.send command.
test_lldbmi_tokens: Add test for MI tokens.
test_lldbmi_badpathexe: Remove check for prompt so test for bad path can be enabled.
Patch from dawn@burble.org.
llvm-svn: 222838
In the initialization list of IOHandlerConfirm, *this is basically casting
IOHandlerConfirm to its base IOHandlerDelegate and passing it to constructor of
IOHandlerEditline which uses it and crashes as constructor of IOHandlerDelegate
is still not called. Re-ordering the base classes makes sure that constructor of
IOHandlerDelegate runs first.
It would be good to have a test case for this case too.
llvm-svn: 222816
These methods are difficult / impossible to implement in a way
that is semantically equivalent to the expectations set by LLDB
for using them. In the future, we should find an alternative
strategy (for example, i/o redirection) for achieving similar
functionality, and hopefully deprecate these APIs someday.
llvm-svn: 222775
- Use canonical date order (per groff & mandoc)
- Fix capitalization on one .Nm
- Remove EOL whitespace
Patch by Baptiste Daroussin in FreeBSD svn r274927.
llvm-svn: 222655
The following lldb unit tests fail check-lldb on ubuntu:
TestDataFormatterStdMap.py
TestDataFormatterStdVBool.py
TestDataFormatterStdVector.py
TestDataFormatterSynthVal.py
TestEvents.py
TestInitializerList.py
TestMemoryHistory.py
TestReportData.py
TestValueVarUpdate.py
These unit test failures are for non-core functionality. The intent is to
reduce the check-lldb FAILS to core functionality FAILS and then circle
back later and fix these FAILS at a later date.
llvm-svn: 222608
This was fixed by making the DWARFFormValue contain the compile unit that it needs so it can decode its form value correctly. Any form value that requires a compile unit will now assert. If any of the assertions that were added are triggered, then code that led to the extraction of the form value without properly setting the compile unit must be fixed immediately.
<rdar://problem/19035440>
llvm-svn: 222602
UnwindLLDB::AddOneMoreFrame to try the fallback unwind plan on
that same stack frame before it tries the fallback unwind plan
on the "next" or callee frame.
In RegisterContextLLDB::TryFallbackUnwindPlan, when we're
trying the fallback unwind plan to see if it is valid, make
sure we change all of the object ivars that might be used in
the process of fetching the CFA & caller's saved pc value
and restore those if we decide not to use the fallback
unwindplan.
<rdar://problem/19035079>
llvm-svn: 222601
(e.g. breakpoints, stop-hooks) before we have any targets - for instance in
your ~/.lldbinit file. These will then get copied over to any new targets
that get created. So far, you can only make stop-hooks.
Breakpoints will have to learn to move themselves from target to target for
us to get them from no-target to new-target.
We should also make a command & SB API way to prime this ur-target.
llvm-svn: 222600
Issue D5632 fixed an issue where linux would dump spurious output to tty on startup (due to a broadcast stop event). After the checkin, it was noticed on FreeBSD a unit test was now failing. On closer investigation I found the test was using the C++ API to launch an inferior while using an SBListener to monitor the public state changes. As on OSx, it was expecting to see:
eStateRunning
eStateStopped
On Linux/FreeBSD, there is an extra state change
eStateLaunching
eStateRunning
eStateStopped
I reworked the test to work for both cases and re-enabled the test of FreeBSD.
Differential Revision: http://reviews.llvm.org/D5837
llvm-svn: 222511
The default value for opt.thread_count was multiprocessing.cpu_count(),
which meant the LLDB_TEST_THREADS environment variable was never used.
It's not easy to pass the -t option to the test run when invoking it
from e.g. 'ninja check-lldb', so having the environment variable as an
option is useful.
Change the logic so that the thread count is set by the first one of:
1. The -t option to test/dosep.py
2. The LLDB_TEST_THREADS environment variable
3. The machine's CPU count from multiprocessing.cpu_count()
llvm-svn: 222501
is treated as a string instead of a FileSpec.
OptionValueFileSpec::SetValueFromCString() passes the c string to
FileSpec::SetFile(str, true /* resolve */) - and with Zachary's
changes to FileSpec we're using llvm::sys::fs::make_absolute() to
do that "resolve" action now, where we used to use realpath().
One important difference between llvm::sys::fs::make_absolute and
realpath is that when they're handed a filename (no directory),
realpath prepends the current working directory *and if the file exists*,
returns that full path. If that file doesn't exist, the caller
uses the basename only.
llvm::sys::fs::make_absolute prepends the current working directory
regardless of whether it exists or not.
I considered having FileSpec::SetFile save the initial pathname,
call FileSpec::Resolve, and then check to see if the Resolve return
path exists - and if not, go back to the original one.
But instead I just went with changing 'target modules load' to treat its
filename argument as a string instead of a FileSpec. This brings it
in line with how 'target modules list' works.
<rdar://problem/18955416>
llvm-svn: 222498
LLDB supports many different register numbering schemes, and these
are typically prefixed with an indicator that lets the user know
what numbering scheme is used. The gcc numbering scheme is
prefixed with gcc, and there are similar ones for dwarf, gdb,
and gcc_dwarf.
LLDB also contains its own internal numbering scheme, but the enum
for LLDB's numbering scheme was prefixed differently. This patch
changes the names of these enums to use the same naming scheme for
the enum values as the rest of the register kinds by removing gpr_
and fpu_ prefixes, and instead using lldb_ prefixes for all enum
values.
Differential Revision: http://reviews.llvm.org/D6351
Reviewed by: Greg Clayton
llvm-svn: 222495
Running a diff against lldb-x86-register-enums.h and the file
modified in this patch, the two enums were completely identical.
Deleting one of them to reduce code noise.
llvm-svn: 222478
This implements the skeleton of a RegisterContext for Windows.
In particular, this implements support only for x86 general purpose
registers.
After this patch, LLDB on Windows can perform basic debugging
operations in a single-threaded inferior process (breakpoint,
register inspection, frame select, unwinding, etc).
Differential Revision: http://reviews.llvm.org/D6322
Reviewed by: Greg Clayton
llvm-svn: 222474
Summary: In noack mode, these checksums are ignored by llgs, but some implementations need them still. Specify these checksums to ease integration.
Test Plan: Run the tests before and after the change and make sure nothing breaks.
Reviewers: clayborg, tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6343
llvm-svn: 222441
where it is retrieving the Return Address register contents
on a target where that's a thing. If we fail to get a valid
RA, we force a switch to the fallback unwind plan. This patch
adds a sanity check for that fallback unwind plan -- it must
get a valid CFA for this frame in addition to being able to
retrieve the caller's PC -- and it correctly marks the unwind
rules as failing if the fallback unwind plan fails.
<rdar://problem/19010211>
llvm-svn: 222301
some commands that will get run if the target crashes.
Also fix the bug where the local .lldbinit file was not getting
sourced before not after the target was created from the file options on the
driver command line.
<rdar://problem/19019843>
llvm-svn: 222295
SWIG is searched under certain paths within python script. CMake can
detect SWIG with find_package(SWIG). This is used iff user checks
LLDB_ENABLE_PYTHON_SCRIPTS_SWIG_API_GENERATION. If
buildSwigWrapperClasses.py does not receive swigExecutable argument,
then the script will use its current search implementation.
llvm-svn: 222262
retrieves the personality routine addr and the
LSDA addr. Don't bother checking with the
"non-call site" unwind plan - this kind of
information is only going to come from the
call site unwind plan.
llvm-svn: 222226
deadlocking when we have the base Unwind class and the HistoryUnwind
subclass both trying to acquire the lock on the same thread to clear
their respective ivar state.
<rdar://problem/18986350>
llvm-svn: 222221
eh_frame data. These two pieces of information are used in the
process of exception handler unwinding on SysV ABI systems.
This patch reads the data from the eh_frame section
(DWARFCallFrameInfo.cpp), allows for it to be saved & read out
of a given UnwindPlan (UnwindPlan.h, UnwindPlan.cpp) - as well
as printing the information in the UnwindPlan::Dump method - and
adds methods to the FuncUnwinders object so that higher levels
can query if a given function has an LSDA / personality routine
defined.
It's only lightly tested, but seems to be working correctly as long
as your have this information in eh_frame. Does not address getting
this information from compact unwind yet on Darwin systems.
<rdar://problem/18742797>
llvm-svn: 222214
Fixed the prompt to not include non-printable characters as it was hosing up the prompt when you ran "command regex foo" and entered multi-line editing mode.
Fixed error strings to include more complete descriptions when bad regular expressions are entered.
Removed the old IOHandlerLinesUpdated function as it is no longer needed (inheriting from IOHandlerDelegateMultiline takes care of what this function used to do).
llvm-svn: 222207
The problem is that editline currently is trying to be smart when we paste things into a terminal window. It detects that input is pending and multi-line input is accepted as long as there is anything pending.
So if you open lldb and paste the text between the quotes:
"command regex carp
s/^$/help/
carp
"
We still still be stuck in the "command regex" multi-line input reader as it will have all three lines:
"s/^$/help/
carp
"
The true fix for this is something Kate Stone will soon work on:
- multi-line input readers must opt into this paste/pending input feature ("expr" will opt into it, all other commands won't)
- If we are in a multi-line input reader that requests this and stuff is pasted, then it will do what it does today
- if we start in a IOHandler that doesn't need/want pending input and text is pasted, and we transistion to a IOHandler that does want this functionality, then disable the pending input. Example text would be:
"frame variable
thread backtrace
expr
for (int i=0;i<10;++i)
(int)printf("i = %i\n", i);
frame select 0
"
When we push the expression multi-line reader we would disable the pending input because we had pending input _before_ we entered "expr".
If we did this first:
(lldb) expr
Then we pasted:
"void foo()
{
}
void bar()
{
}
"
Then we would allow the pending input to not look for an empty line to terminate the expression. We filed radar 19008425 to track fixing this issue.
llvm-svn: 222206
Previously using HostThread::GetNativeThread() required an ugly
cast to most-derived type. This solves the issue by simply returning
the derived type directly.
llvm-svn: 222185
Previously we were directly updating the thread list and stopping
and restarting the process every time threads were created. With
this patch, we queue up thread launches and thread exits, resolve
these all internally, and only update the threads when we get an
UpdateThreadList call. We now only update the private state on
an actual stop (i.e. breakpoint).
llvm-svn: 222178
Editline does not work correctly on Windows. This goes back at
least to r208369, and as a result r210105 was submitted to disable
libedit at runtime on Windows.
More recently, r222163 was submitted which re-writes editline
entirely, but makes the situation even worse on Windows, to the
point that it doesn't even compile. While it would be easy to
fix the compilation failure, this patch simply stops compiling
Editline entirely on Windows, as the simple compilation fix would
still result in a broken use of select on Windows, and as such a
broken implementation of Editline.
Since Editline was already disabled to begin with on Windows, we
don't attempt to fix the compilation failure or the underlying
issues, and instead just disable it "even more".
llvm-svn: 222177
Fixed include:
- Change Platform::ResolveExecutable(...) to take a ModuleSpec instead of a FileSpec + ArchSpec to help resolve executables correctly when we have just a path + UUID (no arch).
- Add the ability to set the listener in SBLaunchInfo and SBAttachInfo in case you don't want to use the debugger as the default listener.
- Modified all places that use the SBLaunchInfo/SBAttachInfo and the internal ProcessLaunchInfo/ProcessAttachInfo to not take a listener as a parameter since it is in the launch/attach info now
- Load a module's sections by default when removing a module from a target. Since we create JIT modules for expressions and helper functions, we could end up with stale data in the section load list if a module was removed from the target as the section load list would still have entries for the unloaded module. Target now has the following functions to help unload all sections a single or multiple modules:
size_t
Target::UnloadModuleSections (const ModuleList &module_list);
size_t
Target::UnloadModuleSections (const lldb::ModuleSP &module_sp);
llvm-svn: 222167
Improvements include:
* Use of libedit's wide character support, which is imperfect but a distinct improvement over ASCII-only
* Fallback for ASCII editing path
* Support for a "faint" prompt clearly distinguished from input
* Breaking lines and insert new lines in the middle of a batch by simply pressing return
* Joining lines with forward and backward character deletion
* Detection of paste to suppress automatic formatting and statement completion tests
* Correctly reformatting when lines grow or shrink to occupy different numbers of rows
* Saving multi-line history, and correctly preserving the "tip" of history during editing
* Displaying visible ^C and ^D indications when interrupting input or sending EOF
* Fledgling VI support for multi-line editing
* General correctness and reliability improvements
llvm-svn: 222163
Fixes include:
- Add a new lldbtest.TestBase function named registerSharedLibrariesWithTarget. This function can be called using the shared libraries for your test suite either as shared library basename ("foo"), path basename ("libfoo.dylib") or full path ("/tmp/lldb/test/lang/c/carp/libfoo.dylib"). These shared libraries are then registered with the target so they will be downloaded when the test is run remotely.
- Changed a lot of tests over to use SBDebugger::CreateTarget(...) calls instead of using "file a.out" commands.
- Cleaned up some tests to add new locations for breakpoints that all compilers should be able to abide by. Some tests and constants being loaded into values of structs and some compilers like arm64 will often combine two constant data loads into a single source line so some breakpoint locations were not being set correctly. Adding lines like 'puts("")' allow us to lock onto a source line that will have code.
llvm-svn: 222156
- Added a new "--apple-sdk" flag that can be specified on Darwin only so the correct cross compilers can be auto-selected without having to specify the "--compiler" flag.
- Set SDKROOT if needed
llvm-svn: 222153
This creates a TargetThreadWindows class and updates the thread
list of the Process with the main thread. Additionally, we
fill out a few more overrides of Process base class methods. We
do not yet update the thread list as threads are created and/or
destroyed, and we do not yet propagate stop reasons to threads as
their states change.
llvm-svn: 222148
This test has intermittently failed on FreeBSD for quite some time when
run as part of the full test suite. It generally passes when run by
itself. Mark as expected failure for now to reduce buildbot noise.
llvm.org/pr15039 test fails intermittently on FreeBSD
llvm-svn: 222134
information from the compact unwind section used on darwin
for exception handling, and dump that information..
The UNWIND_X86_64_MODE_RBP_FRAME and UNWIND_X86_64_MODE_DWARF
entries look to be handled correctly.
UNWIND_X86_64_MODE_STACK_IMMD and UNWIND_X86_64_MODE_STACK_IND
are still a work in progress.
Only x86_64 is supported right now. Given that this is an
experiment in parsing the section contents, I don't expect to
add other architectures; they are trivial variations on this
arch. There exists a real dumper included in the Xcode tools,
unwinddump.
llvm-svn: 222127
relative paths, like:
/whatever/llvm/lib/Sema/../../include/llvm/Sema/
That causes problems with our type uniquing, since we use the declaration file
and line as one component of the uniquing, and different ways of getting to the
same file will have different directory spellings, though they are functionally
equivalent. We end up with two copies of the exact same type because of this,
and that makes the expression parser give "duplicate type" errors.
I added a method to resolve paths with ../ in them and used that in the FileSpec::Equals,
for comparing Declarations and for doing Breakpoint compares as well, since they also
suffer from this if you specify breakpoints by full path (since nobody knows what
../'s to insert...)
<rdar://problem/18765814>
llvm-svn: 222075
Effectively removes -lpthreads from linux/gcc build of test programs in test/api/multithreaded. This was done due to that combination causing a test program to hang due, likely due to an issue with gcc linker and libstdc++ conflicting pthreads code in test program and pthread used by lldb. Issue has been documented at:
http://llvm.org/bugs/show_bug.cgi?id=21553
Differential Revision: http://reviews.llvm.org/D5838
llvm-svn: 222031
Summary: Something like "core:1" would match and try to be interpreted by the following code otherwise.
Test Plan: Run tests and make sure the ones failing previously now pass.
Reviewers: tfiala, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6257
llvm-svn: 221980
Summary: These checksums are ignored by llgs but some implementations require them to be specified properly.
Test Plan: Re-run llgs tests with the checksums and make sure we don't break anything.
Reviewers: tfiala, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6254
llvm-svn: 221927
The issues were:
- If you called this function with any arch other than the default target architecture, creating the target would fail because the Target::GetDefaultArchitecture() would not match the single architecture in the file specified. This caused running the test suite remotely with lldb-platform to fail many many tests due to the bad target.
- It would specify the currently selected platform which might not work for the specified platform
All other SBDebugger::CreateTarget calls do not assume an architecture or platform and if they aren't specified, they don't auto select the wrong one for you.
With this fix, SBTarget SBDebugger::CreateTarget (const char *filename) now behaves like the other SBDebugger::CreateTarget() variants.
llvm-svn: 221908
RegisterContextLLDB. I have core files of half a dozen tricky
unwind situations on x86/arm and they're all working pretty much
correctly at this point, but we'll need to keep an eye out for
unwinder regressions for a little while; it's tricky to get these
heuristics completely correct in all unwind situations.
<rdar://problem/18937193>
llvm-svn: 221866
Part of TestConcurrentEvents starts threads that are supposed to be
delayed by one second.
Test was adding "delay" threads to the "actions" thread list instead
of the "delay_actions" list, which caused them to be started without
delay.
llvm-svn: 221859
This sends notifications for module load / unload to the process
plugin, and also manages the state more accurately during the
loading sequence.
Similar work by Virgile Bello was referenced during the
implementation of this patch.
Differential Revision: http://reviews.llvm.org/D6224
llvm-svn: 221807
Due to a previous multi-threaded design involving message
passing, we used message classes to pass event information
to the delegate. Since the multi-threaded design has gone
away, we simplify this by passing event arguments as direct
function parameters, which is more clear and easier to
understand.
llvm-svn: 221806
After r221575 TestCallStopAndContinue and TestCallThatRestarts started
crashing on FreeBSD with a null temporary_module_sp in
RegisterContextLLDB::InitializeNonZerothFrame().
llvm-svn: 221805
The addition of RegisterNumber introduced a bug where if the PC is stored in a
return address register, such as on ARM and PowerPC, this register number is
retrieved and used, but never checked in the row if it's saved. Correct this by
setting the variable that's used to the new register number.
Patch by Jason Molenda.
llvm-svn: 221790
Summary:
Taking advantage of the new 'CFAIsRegisterDereferenced' CFA register type, add
full stack unwind support to the PowerPC/PowerPC64 ABI. Also, add a new
register set for powerpc32-on-64, so the register sizes are correct. This also
requires modifying the ProcessMonitor to add support for non-uintptr_t-sized
register values.
Reviewers: jasonmolenda, emaste
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D6183
llvm-svn: 221789
Summary:
PowerPC handles the stack chain with the current stack pointer being a pointer
to the backchain (CFA). LLDB currently has no way of handling this, so this
adds a "CFA is dereferenced from a register" type.
Discussed with Jason Molenda, who also provided the initial patch for this.
Reviewers: jasonmolenda
Reviewed By: jasonmolenda
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D6182
llvm-svn: 221788
ObjectFileMachO. It's close but we seem to be missing some
of the memory region segments - not exactly sure how that's
happening. The register context writing into the LC_THREAD
load commands is working correctly though.
Slightly reordered the arm64 definitions in ArchSpec.cpp so
when we look for an arm64 core file definiton we're getting
a cpu subtype of CPU_ANY which we can't put in the mach
header of a core file. Make the first definition we find by
linear search have the currently correct '1' cpu subtype.
llvm-svn: 221743
I went back and forth on removing this - and tried dropping it for
a few weeks. But when you're working at an assembly language, it
really is helpful to have this displayed to show where the current
pc is.
llvm-svn: 221682
being asked about symbols it doesn't know about. If
it's asked about a symbol by mangled name and it finds
nothing, then it will try again with the demangled
base name.
llvm-svn: 221660
runtime. This eliminates potential confusion
when the compiler has to deal with these weird
types later on.
One day I'd like to actually generate the proper
templates, but this is not the day that I write
the parser code to do that.
<rdar://problem/18887634>
llvm-svn: 221658
- A correctness issue: with assertions disabled,
ReadQuotedString would misbehave; and
- A performance issue: BuildType used a long
chain of if()s; I changed that to two switch
statements. That also makes the code much
nicer to step through when debugging it.
llvm-svn: 221651
structures are parsed safely by the Objective-C runtime.
Also made some modifications to the way we parse structs
in the runtime to avoid mis-parsing @ followed by the name
of the next field.
<rdar://problem/18887634>
llvm-svn: 221643
This patch implements basic support for stopping at breakpoints
and resuming later. While a breakpoint is stopped at, LLDB will
cease to process events in the debug loop, effectively suspending
the process, and then resume later when ProcessWindows::DoResume
is called.
As a side effect, this also correctly handles the loader breakpoint
(i.e. the initial stop) so that LLDB goes through the correct state
sequence during the initial process launch.
llvm-svn: 221642
out we only want to roll back text that was in the
buffer to begin with, so it's not necessary to
provide a pushback stack.
I'm going to use this slightly cleaner API to perform
lookahead for the Objective-C runtime type parser.
llvm-svn: 221640
MSVC warns that not all control paths return a value when a switch
doesn't have a default case handler. Changed explicit value checks
to a default check.
Also, it caught a case where bitwise AND was being used instead of
logical AND. I'm not sure what this fixes, but presumably it is
not covered by any kind of test case.
llvm-svn: 221636
r221575 introduced a NoreturnUnwind test that did not skip the dsym
test on non-darwin platforms, and had the @dwarf_test case as an exact
copy of the dsym case (including the test name, test_with_dsym).
llvm-svn: 221611
it in RegisterContext.cpp.
There's a lot of bookkeeping code in RegisterContextLLDB where it has
to convert between different register numbering schemes and it makes
some methods like SavedLocationForRegister very hard to read or
maintain. Abstract all of the details about different register numbering
systems for a given register into this new class to make it easier
to understand what the method is doing.
Also add register name printing to all of the logging -- that's easy to
get now that I've got an object to represent the register numbers.
There were some gnarly corner cases of this method that I believe
I've translated correctly - initial testing looks good but it's
possible I missed a corner case, especially with architectures which
uses a link-register aka return address register like arm32/arm64.
Basic behavior is correct but there are a lot of corner casese that are
handled in this method ...
llvm-svn: 221577
If a noreturn function was the last function in a section,
we wouldn't correctly back up the saved-pc value into the
correct section leading to us showing the wrong function in
the backtrace.
Also add a backtrace test with an attempt to elicit this
particular layout. It happens to work out with clang -Os
but other compilers may not quite get the same layout I'm
getting at that opt setting. We'll still be exercising the
basic noreturn handling in the unwinder even if we don't get
one function at the very end of a section.
<rdar://problem/16051613>
llvm-svn: 221575
Originally the idea was that we would queue requests to a master
thread that would dispatch them to other slave threads each
responsible for debugging an individual process. This might make
some scenarios more scalable and responsive, but for now it seems
to be unwarranted complexity for no observable benefit.
llvm-svn: 221561
Jason Molenda