To fix this I added a new method to TestBase:
def getRerunArgs(self):
return " -f %s.%s" % (self.__class__.__name__, self._testMethodName)
The InlineTest which inherits from TestBase then overrides this function with a custom version which does the right thing.
llvm-svn: 225407
Differential Revision: http://reviews.llvm.org/D6797
lldb-gdbserver statically links all llvm dependencies. This allows
dead stripping code and reduces total binary size.
This change modifies lldb-plaform to static link llvm dependencies
like lldb-gdbserver.
llvm-svn: 225398
This was causing a race condition where DoDestroy() would acquire
the lock and then initiate a shutdown and then wait for it to
complete. But part of the shutdown involved acquiring the same
lock from a different thread. So the main thread would timeout
waiting for the shutdown to complete and return too soon.
The end result of this is that SBProcess::Kill() was broken on
Windows.
llvm-svn: 225297
A recent POSIX host thread issue where HostThreadPosix::Join() wasn't returning the thread result was responsible for this regression, yet we had no test case covering this so it wasn't discovered.
llvm-svn: 225284
Summary:
GCC emits DW_TAG_subrange_type for static member arrays, but with no
attributes. This in turn results in wrong type/value of the array when
printing with 'target variable <array var name>'. This patch fixes this
so that the array value is printed in this format:
(<element type> []) <array var name> = {}
Earlier, the array was being interpreted to be of its element type.
Note: This does not fix anything to do with 'expr' or 'p' commands.
Those commands still error out complaining about incomplete types.
Test Plan: dotest.py -p TestStaticVariables
Reviewers: emaste, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6799
llvm-svn: 225219
When Python does not exist on the system path, LLDB will be unable
to load it. Fix this by copying the dll to the output folder so
it will be side-by-side with lldb.exe.
llvm-svn: 225218
Passing the argument string from dosep to dotest was failing on
Windows due to the fact that Windows uses \ for its path separator.
As a result, shlex.split() was treating it as an escape character.
This fixes the issue by telling shlex.split() to not use posix mode
when running on Windows.
llvm-svn: 225195
This patch updates the list of supported platforms to include
Windows, and also provides some detailed getting started instructions
for building LLDB on Windows.
Differential Revision: http://reviews.llvm.org/D6805
llvm-svn: 225023
Following changes were done.
1. Remove the extra line after -exec-run.
2. Remove check for prompt.
3. Remove 'quit' command.
Initial patch was contributed by ki.stfu@gmail.com.
llvm-svn: 224990
variable (now provided both by the normal parent LLVM CMake files and by
the LLVMConfig.cmake file used by the standalone build).
This allows LLDB to build into and install into correctly suffixed
libdirs. This is especially significant for LLDB because the python
extension building done by CMake directly uses multilib suffixes when
the host OS does, and the host OS will not always look back and forth
between them. As a consequence, before LLVM, Clang, and LLDB (and every
other subproject) had support for using LLVM_LIBDIR_SUFFIX, you couldn't
build or install LLDB on a multilib system with its python extensions
enabled. With this patch (on top of all the others I have submitted
throughout the project), I'm finally able to build and install LLDB on
my system with Python support enabled. I'm also able to actually run the
LLDB test suite, etc. Now, a *huge* number of the tests still fail on my
Linux system, but hey, actually running them and them testing the
debugger is a huge step forward. =D
llvm-svn: 224930
the same way the LLVM CMake build does, notably using the proper CMake
module and specifically requesting an older Python version. LLDB relies
pretty heavily on not using Python 3 at this point, and without this
patch it ends up trying to use Python 3 which ends quite badly. =] With
this, I'm able to build LLDB in its standalone mode successfully on
Linux when I have both Python 2.7 and Python 3.3 installed.
llvm-svn: 224929
This completes the compact unwind support for x86 targets.
I'm still skipping the UNWIND_X86_64_MODE_STACK_IND encodings for
x86_64 right now because clang was emitting bad data for this form
until it was fixed in r217020 circa Sep 2014.
arm64 parsing still needs to be added.
llvm-svn: 224698
Most of the changes are to the FuncUnwinders class -- as we've added
more types of unwind information, the way this class was written was
making it a mess to maintain. Instead of trying to keep one
"non-call site" unwind plan and one "call site" unwind plan, track
all the different types of unwind plans we can possibly retrieve for
each function and have the call-site/non-call-site accessor methods
retrieve those.
Add a real "fast unwind plan" for x86_64 / i386 -- when doing an
unwind through a function, this only has to read the first 4 bytes
to tell if the function has a standard prologue sequence. If so,
we can use the architecture default unwind plan to backtrace
through this function. If we try to retrieve the save location for
other registers later on, a real unwind plan will be used. This
one is just for doing fast backtraces.
Change the compact unwind plan importer to fill in the valid address
range it is valid for.
Compact unwind, in theory, may have multiple entries for a single
function. The FuncUnwinders rewrite includes the start of supporting
this correctly. In practice compact unwind encodings are used for
the entire range of the function today -- in fact, sometimes the same
encoding is used for multiple functions that have the same unwind
rules. But I want to handle a single function that has multiple
different compact unwind UnwindPlans eventually.
llvm-svn: 224689
When lldb has a binary with protected section contents,
don't use the on-disk representation of that compact
uwnind -- read it only out of live memory where it has
been decrypted.
llvm-svn: 224670
Summary:
If we do not mark them as skip, they are still executed, which in
turn is leading to an assertion failure. The change also adds
skipIfLinux to a testlet which was not previously marked with
skipIfLinux. This is because running even that test let leads to an
assertion failure.
Test Plan: dotest.py -C clang -p TestEvents.py
Reviewers: vharron
Reviewed By: vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6715
llvm-svn: 224644
Summary:
The test is question here is already annotated
with @expectedFailureDarwin(9980907).
This change also removes an uneccessary (and probably wrong) logic of
byssing few asserts if the compiler is not clang or llvm-gcc.
Both GCC and Clang emit incomplete debug info. Clang emits this:
< 1><0x00000026> DW_TAG_class_type
DW_AT_name "A"
DW_AT_byte_size 0x00000001
DW_AT_decl_file 0x00000001
DW_AT_decl_line 0x0000001b
< 2><0x0000002e> DW_TAG_member
DW_AT_name "g_points"
DW_AT_type <0x0000003b>
DW_AT_decl_file 0x00000001
DW_AT_decl_line 0x0000001e
DW_AT_external yes(1)
DW_AT_declaration yes(1)
DW_AT_accessibility DW_ACCESS_public
< 1><0x0000003b> DW_TAG_array_type
DW_AT_type <0x00000046>
< 2><0x00000040> DW_TAG_subrange_type
DW_AT_type <0x0000007b>
Notice that the DIE at 0x40 does not specify an upperbound. This is with
Clang-3.5 and Clang ToT.
GCC emits this:
< 1><0x000000aa> DW_TAG_class_type
DW_AT_name "A"
DW_AT_byte_size 0x00000001
DW_AT_decl_file 0x00000001
DW_AT_decl_line 0x0000001b
DW_AT_sibling <0x000000c1>
< 2><0x000000b4> DW_TAG_member
DW_AT_name "g_points"
DW_AT_decl_file 0x00000001
DW_AT_decl_line 0x0000001e
DW_AT_type <0x000000c1>
DW_AT_external yes(1)
DW_AT_accessibility DW_ACCESS_public
DW_AT_declaration yes(1)
< 1><0x000000c1> DW_TAG_array_type
DW_AT_type <0x0000007e>
DW_AT_sibling <0x000000cc>
< 2><0x000000ca> DW_TAG_subrange_type
The DIE at 0xca is missing attributes. This is with gcc-4.8.2.
Test Plan: dotest.py -C clang -P TestStaticVariables.py
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6713
llvm-svn: 224643
Summary:
TestCompletion was broken for Ubuntu (and probably for Debian also).
The issue was that the lldb prompt in color (which is the default
behavior) was confusing pexpect.
Test Plan: "http://199.223.233.39:8011/lldb-try-clang-build-clang-test/"
Reviewers: zturner, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6671
llvm-svn: 224642
The issue was we had a global variable that was a pointer, and the address type of the children wasn't "load address" when it needed to be. Full details are in the comments of the changes.
<rdar://problem/15107937>
llvm-svn: 224559
As a first step in addressing Bug #21921 this patch prefers
the python-based SWIG generation by default rather than the
shell-based SWIG generation any time python is enabled
(e.g. LLDB_DISABLE_PYTHON is 0).
Additionally, this patch changes the default value of
LLDB_DISABLE_PYTHON from 1 to 0 on Windows.
Anyone not using the CMake build is unaffected by this patch.
llvm-svn: 224543
Summary:
This is part of the Linux remote platform work. Displaying the local
kernel information when remote debugging doesn't make sense, so we
should verify if we are in host mode before doing so.
Test Plan:
Connect to a remote linux platform mode daemon with `platform select
remote-linux` followed by `platform connect ...`, and look at the output
of `platform status`.
Reviewers: tfiala, clayborg, vharron, compnerd
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D5928
llvm-svn: 224540
This fixes compilation failures in the 64-bit build of LLDB on Windows.
Patch by Aidan Dodds
Differential Revision: http://reviews.llvm.org/D6704
llvm-svn: 224528
For some reason MSVC ICEs when trying to index into a map using
a temporary object. Work around this by separating out the call
into multiple lines.
Patch by Aidan Dodds
Differential Revision: http://reviews.llvm.org/D6702
Reviewed by: Zachary Turner, Greg Clayton
llvm-svn: 224443
This patch makes a number of improvements to the Pipe interface.
1) An interface (PipeBase) is provided which exposes pure virtual
methods for any implementation of Pipe to override. While not
strictly necessary, this helps catch errors where the interfaces
are out of sync.
2) All methods return lldb_private::Error instead of returning bool
or void. This allows richer error information to be propagated
up to LLDB.
3) A new ReadWithTimeout() method is exposed in the base class and
implemented on Windows.
4) Support for both named and anonymous pipes is exposed through the
base interface and implemented on Windows. For creating a new
pipe, both named and anonymous pipes are supported, and for
opening an existing pipe, only named pipes are supported.
New methods described in points #3 and #4 are stubbed out on posix,
but fully implemented on Windows. These should be implemented by
someone on the linux / mac / bsd side.
Reviewed by: Greg Clayton, Oleksiy Vyalov
Differential Revision: http://reviews.llvm.org/D6686
llvm-svn: 224442
names can then be used in place of breakpoint id's or breakpoint id
ranges in all the commands that operate on breakpoints.
<rdar://problem/10103959>
llvm-svn: 224392
lld-link shells out to MSVC for certain types of work, and this
results in some MSVC output files being generated even though
clang / lld are the compiler / linker. This is expected, so we
make sure to clean these output files on make clean.
llvm-svn: 224345
The compact unwind importer is getting the wrong unwind info for one
case that I found. I haven't been able to fix the problem tonight
and I don't want to leave TOT behaving incorrectly, so just ignore
compact unwind until I can get to the bottom of this.
llvm-svn: 224321
Fixed:
1 - try the symbol table symbol for an ObjC ivar and use it if available
2 - fall back to using the runtime data since it is slower to gather via memory read
3 - Fixed our hidden ivars test case to test this to ensure we don't regress
4 - split out a test case in the hidden ivars to cover only the part that was failing so we don't have an expected failure for all of the other content in the test.
<rdar://problem/18882687>
llvm-svn: 224306
Our actual view of registers is a set of register sets, each one of which contains a subset of the actual registers
This makes trivial scripting operations tedious ("I just want to read r7!")
This helper allows things like: print lldb.frame.reg["r7"]
Fixes rdar://19185662
llvm-svn: 224275
This saga started with a hang on OSX. 2 solutions were proposed.
1) 'select' based solution works ok on OSX but slows down test completion time
on Linux many times.
2) 'ioctl' base solution also works but it causes heavy processor usage on OSX
as reported by Ilia K.
But as the original hang did not occur on Linux so this commit re-introduces the
'select' in conditional code so that it only runs for OSX. There is no need for
this 'fix' to run on Linux.
Initial patch by Ilia K <ki.stfu@gmail.com>. A few changes were made by me.
llvm-svn: 224258
Summary:
If a stream contains an empty string, no need to append it to the output
(otherwise we end up with a blank line). Also, no need to print a status
message when the state changes to connected, as this string brings no
information -- "Process 0" does not mean anything to the user, and the
process being connected has no meaning either.
Test Plan:
Connect to a remote linux platform mode daemon with `platform select
remote-linux` followed by `platform connect ...`, create a target and
run it, observe the output. Also, run the full test suite (dosep.py).
Before:
(lldb) [...] connect, etc.
(lldb) r
Process 0 connected
Process 5635 launched: '/Users/sas/Source/test' (x86_64)
Process 5635 stopped
After:
(lldb) [...] connect, etc.
(lldb) r
Process 5635 launched: '/Users/sas/Source/test' (x86_64)
Process 5635 stopped
Reviewers: tfiala, vharron, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6593
llvm-svn: 224188
Default time limit is 5 minutes.
Override the default timeout of 5 minutes with LLDB_TEST_TIMEOUT.
LLDB_TEST_TIMEOUT=10m
Override the timeout for individual tests with LLDB_[TESTNAME]_TIMEOUT.
E.g., LLDB_TESTCONCURRENTEVENTS_TIMEOUT=2m
Set to "0" to run without timeout.
Submitted for Chaoren Lin
llvm-svn: 224171
Summary:
This moves
- SyntheticChildrenFrontEnd::CreateValueObjectFromExpression
- SyntheticChildrenFrontEnd::CreateValueObjectFromAddress
- SyntheticChildrenFrontEnd::CreateValueObjectFromData
outside the `#ifndef LLDB_DISABLE_PYTHON` since it doesn't seem to depend on python being available and indeed breaks the build when python is disabled.
Reviewers: granata.enrico
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6646
llvm-svn: 224170
When running the test suite on Windows, we can't have Windows popping
up dialogs when LLDB crashes in native code because it will hang
the test suite. This patch silences those dialogs by checking an
environment variable at startup and configuring Windows based on
its value.
This patch also adds an environment variable to force inferiors to
never spawn in their own console window. This is useful to prevent
new window spawm when running the test suite.
Reviewed by: Scott Graham
Differential Revision: http://reviews.llvm.org/D6628
llvm-svn: 224137
Objective-C type in the runtime. This is not actually
true, it's entirely possible to say
@class DoesntExist;
@interface DoesExist {
DoesntExist *whyyyyy;
}
@end
and this code will not only compile but also run. So
this assertion will fire in situations users might
encounter.
I left the assertion enabled in debug mode, because we
could still catch a case we're not aware of (i.e., a
class that we *ought* to have found but where somehow
we mis-parsed the name).
<rdar://problem/19151914>
llvm-svn: 224038
Objective-C types and enums in modules. We now have
a three-stage fallback when looking for methods and
properties: first the DWARF, second the modules, third
the runtime.
<rdar://problem/18782288>
llvm-svn: 223939
Fix PR21802 by correcting the destruction order of
`ClangExpressionParser` and `IRExecutionUnit` in `ClangFunction`. The
former has hooks into the latter -- i.e., `clang::CGDebugInfo` points at
the `LLVMContext` -- so it needs to be torn down first.
This was exposed by r223802 in LLVM, which started doing work in the
`CGDebugInfo` teardown.
llvm-svn: 223916
Function pointers had a summary generated for them bypassing formatters, directly as part of the ValueObject subsystem
This patch transitions that code into a hardcoded summary
llvm-svn: 223906
clang does not yet support MS-ABI record layout for externally-sourced
ASTs. As a result, attempting to format something that requires data
layout results in undefined behavior in clang, in this case an assert.
http://llvm.org/pr21800 tracks fixing this on the clang side.
llvm-svn: 223868
The issue with Thumb IT (if/then) instructions is the IT instruction preceeds up to four instructions that are made conditional. If a breakpoint is placed on one of the conditional instructions, the instruction either needs to match the thumb opcode size (2 or 4 bytes) or a BKPT instruction needs to be used as these are always unconditional (even in a IT instruction). If BKPT instructions are used, then we might end up stopping on an instruction that won't get executed. So if we do stop at a BKPT instruction, we need to continue if the condition is not true.
When using the BKPT isntructions are easy in that you don't need to detect the size of the breakpoint that needs to be used when setting a breakpoint even in a thumb IT instruction. The bad part is you will now always stop at the opcode location and let LLDB determine if it should auto-continue. If the BKPT instruction is used, the BKPT that is used for ARM code should be something that also triggers the BKPT instruction in Thumb in case you set a breakpoint in the middle of code and the code is actually Thumb code. A value of 0xE120BE70 will work since the lower 16 bits being 0xBE70 happens to be a Thumb BKPT instruction.
The alternative is to use trap or illegal instructions that the kernel will translate into breakpoint hits. On Mac this was 0xE7FFDEFE for ARM and 0xDEFE for Thumb. The darwin kernel currently doesn't recognize any 32 bit Thumb instruction as a instruction that will get turned into a breakpoint exception (EXC_BREAKPOINT), so we had to use the BKPT instruction on Mac. The linux kernel recognizes a 16 and a 32 bit instruction as valid thumb breakpoint opcodes. The benefit of using 16 or 32 bit instructions is you don't stop on opcodes in a IT block when the condition doesn't match.
To further complicate things, single stepping on ARM is often implemented by modifying the BCR/BVR registers and setting the processor to stop when the PC is not equal to the current value. This means single stepping is another way the ARM target can stop on instructions that won't get executed.
This patch does the following:
1 - Fix the internal debugserver for Apple to use the BKPT instruction for ARM and Thumb
2 - Fix LLDB to catch when we stop in the middle of a Thumb IT instruction and continue if we stop at an instruction that won't execute
3 - Fixes this in a way that will work for any target on any platform as long as it is ARM/Thumb
4 - Adds a patch for ignoring conditions that don't match when in ARM mode (see below)
This patch also provides the code that implements the same thing for ARM instructions, though it is disabled for now. The ARM patch will check the condition of the instruction in ARM mode and continue if the condition isn't true (and therefore the instruction would not be executed). Again, this is not enable, but the code for it has been added.
<rdar://problem/19145455>
llvm-svn: 223851
a register value that is live in the stack frame 0 register context.
Fixes a problem where retrieving a register value on stack frame #n
would involved O(n!) stack frame checks. This could be very slow on
a deep stack when retrieving register values that had not been
modified/saved by any of the stack frames. Not common, but annoying
when it was hit.
<rdar://problem/19010211>
llvm-svn: 223843
Because of the way they are created, synthetic children cannot (in general) have a sane expression path
A solution to this would be letting the parent front-end generate expression paths for its children
Doing so requires a significant amount of refactoring, and might not always lead to better results (esp. w.r.t. C++ templates)
This commit takes a simpler approach:
- if a synthetic child is of pointer type and it's a target pointer, then emit *((T)value)
- if a synthetic child is a non-pointer, but its location is in the target, then emit *((T*)loadAddr)
- if a synthetic child has a value, emit ((T)value)
- else, don't emit anything
Fixes rdar://18442386
llvm-svn: 223836
track of the checksum of the object so we can
track if it is modified. This fixes a testcase
(test/expression_command/issue_11588) on OS X.
Patch by Enrico Granata.
llvm-svn: 223830
- adds a new flag to mark ValueObjects as "synthetic children generated"
- vends new Create functions as part of the SyntheticChildrenFrontEnd that set the flag automatically
- moves synthetic child providers over to using these new functions
No visible feature change, but preparatory work for feature change
llvm-svn: 223819
Getting this working correctly is a significant amount of work.
Assertions on Windows show up as error code 0xC0000409, which is
STATUS_STACK_BUFFER_OVERRUN. In order to accurately determine
that this is not just any stack buffer overrun, but one triggered
by a call to abort, we would need to analyze the call stack. This
in turn requires better symbol support for Windows executables,
and work on LLDB to make stack frames better on Windows.
For now, these are XFAIL'ed and tracked in http://llvm.org/pr21793.
llvm-svn: 223816
Summary:
Test Plan: Connect to a remote implementing the platform protocol (ds2 in this case), run `platform process list` and see processes being displayed.
Reviewers: vharron, tfiala, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6571
llvm-svn: 223752
Such a persisted version is equivalent to evaluating the value via the expression evaluator, and holding on to the $n result of the expression, except this API can be used on SBValues that do not obviously come from an expression (e.g. are the result of a memory lookup)
Expose this via SBValue::Persist() in our public API layer, and ValueObject::Persist() in the lldb_private layer
Includes testcase
Fixes rdar://19136664
llvm-svn: 223711
This is a resubmit of r223548, which was reverted due to breaking
tests on Linux and Mac.
This resubmit fixes the reason for the revert by adding back some
accidentally removed code which appends -c to the command line
when running /bin/sh.
This resubmit also differs from the original patch in that it sets
the architecture on the ProcessLaunchInfo. A follow-up patch will
refactor this to separate the logic for different platforms.
Differential Revision: http://reviews.llvm.org/D6553
Reviewed By: Greg Clayton
llvm-svn: 223695
There was an error in ORing mask which is used for getting a list of variables.
Previously, these constants were unnamed, and possible it become the reason of this
bug. Also added test case for -stack-list-local and -stack-list_arguments.
Patch from Ilia K <ki.stfu@gmail.com>.
llvm-svn: 223674
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
Vince Harron