This works on SVN but is a bit fragile on the Swift branch.
I'm adding the test to both, so we have this path covered.
<rdar://problem/32372372>
llvm-svn: 304314
Summary:
- Added API to access data types
-- integer, double, array, string, boolean and dictionary data types
-- Earlier user had to parse through the string output to get these
values
- Added Test cases for API testing
- Added new StructuredDataType enum in public include file
-- Replaced locally-defined enum in StructuredData.h with this new
one
-- Modified other internal files using this locally-defined enum
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: clayborg, lldb-commits
Reviewed By: clayborg
Subscribers: labath
Differential Revision: https://reviews.llvm.org/D33434
llvm-svn: 304138
r303972 used GetValueForKeyAsInteger with mismatched types (e.g.
instantiating with uint64_t, but passing a size_t argument), which
manifested itself on 32-bit architectures.
The intended usage of these functions was to not specify the type
explicitly, and let the compiler figure that out, so switch to that kind
of usage instead.
llvm-svn: 303988
Summary:
The changes consist of new packets for trace manipulation and
trace collection. The new packets are also documented. The packets
are capable of providing custom trace specific parameters to start
tracing and also retrieve such configuration from the server.
Reviewers: clayborg, lldb-commits, tberghammer, labath, zturner
Reviewed By: clayborg, labath
Subscribers: krytarowski, lldb-commits
Differential Revision: https://reviews.llvm.org/D32585
llvm-svn: 303972
In the absense of a more specific handler for TRAP_CAP (generated by
ENOTCAPABLE or ECAPMODE while in capability mode) treat it as a trace
trap. Obtained from FreeBSD r318884.
We should later add an option to have LLDB control the trapcap procctl
(as with ASLR), as well as report a specific stop reason. For now this
change eliminates an assertion failure from LLDB.
llvm-svn: 303965
lldb: libedit produces garbled, unusable input on Linux
Apply patch from Christos Zoulas, upstream libedit developer.
It has been tested on NetBSD/amd64.
New code supports combination of wide libedit and disabled
LLDB_EDITLINE_USE_WCHAR, which was the popular case on Linux
systems.
llvm-svn: 303907
This reverts commit r303847 as it introduces a number of regressions.
Investigation has showed that we are parsing the CIE entries in the
debug_frame section incorrectly -- we are parsing them the same way as
eh_frame, but the entries in debug_frame have a couple of extra entries
which have not been taken into account.
llvm-svn: 303854
This is a resubmit of r303732, which was reverted due to a regression.
The original patch caused a regression in TestLoadUnload, which has only showed
up when running the remote test suite. The problem there was that we interrupted
the target just as it has hit the rendezvous breakpoint in the dlopen call. This
meant that the stop reason was set to "breakpoint" even though the event would
not have been broadcast if we had not stopped the process. I fix this by
checking StopInfo->ShouldNotify() before stopping.
I also add a new test for the handling of conditional breakpoints in
expressions, which I noticed to be broken (pr33164)
Differential Revision: https://reviews.llvm.org/D33283
llvm-svn: 303848
There are some differences between eh_frame and debug_frame formats that
are not considered by DWARFCallFrameInfo::GetFDEIndex. An FDE entry
contains CIE_pointer in debug_frame in same place as cie_id in eh_frame.
As described in dwarf standard (section 6.4.1), CIE_pointer is an
"offset into the .debug_frame section". So, variable cie_offset should
be equal cie_id for debug_frame.
FDE entries with zeroth CIE pointer (which is actually placed in cie_id
variable) shouldn't be ignored also.
I have also added a little change which allow to use debug_info section
when eh_frame is absent. This case really can take place on some platforms.
Patch from tatyana-krasnukha.
https://reviews.llvm.org/D33504
llvm-svn: 303847
During some cleanup the test for whether the thread plan
accepted an iteration count was reversed, so we give a
warning when it will actually work, and don't when it won't.
<rdar://problem/32379280>
llvm-svn: 303832
Summary:
The function had logic to handle the case when the expression terminated
while we were trying to halt the process, but it failed to take into
account the possibility that the expression stopped because it hit a
breakpoint. This was caused by the fact that the handling of the stopped
events was duplicated for the "halting" and regular cases (the regular
case handled this situation correctly). I've tried to merge these two
cases into one to make sure they stay in sync.
I should call out that the two cases were checking whether the thread
plan has completed in slightly different ways. I am not sure what is the
difference between them, but I think the check should be the same in
both cases, whatever it is, so I just took the one from the regular
case, as that is probably more tested.
For the test, I modified TestUnwindExpression to run the expression with
a smaller timeout (this is how I found this bug originally). With a 1ms
one thread timeout, the test failed consistently without this patch.
Reviewers: jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D33283
llvm-svn: 303732
Summary: I didn't change all instances of i to I in this loop. I am a bad person and should feel bad. :(
Reviewers: sas
Differential Revision: https://reviews.llvm.org/D33456
Change by Alex Langford <apl@fb.com>
llvm-svn: 303677
LLVM::AttributeList recently had getNumSlots() removed, which broke the
build. This fixes the build using functions introduced in the
update to LLVM::AttributeList.
Change by Alex Langford <apl@fb.com>
llvm-svn: 303674
Summary:
A change in swig 3.0.9 has caused it to generate modules incompatible
with us using them as __init__.py (bug #769). Swig 3.0.11 adds a setting to help
fix this problem, so use that. Support for older versions of swig remains
unaffected.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D33409
llvm-svn: 303627
Change 302872 was a massive rename of the Error class to Status.
The change included an incorrect rename of the "Status" window
in the LLDB GUI from "Status to "Error". This patch undoes this incorrect
rename and restores the status window's correct name.
Differential Revision: https://reviews.llvm.org/D33241
Patch by Brian Gianforcaro.
llvm-svn: 303553
Summary:
This adds functions to convert between llvm::Error and Status classes.
Posix errors in Status are represented as llvm::ECError, and the rest as
llvm::StringError.
For the conversion from Error to Status, ECError is again represented as
a posix error in Status, while other errors are stored as generic errors
and only the string value is preserved.
Reviewers: zturner, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D33241
llvm-svn: 303348
For remote targets we need to call registerSharedLibrariesWithTarget to
make sure they are installed alongside main executable. This also
required a small fixup in the the mentioned function as in this case
"One" was both a directory name and a library name template. I fixed it
to make sure it checks that the string refers to a file before it
assumed it was a full library path.
llvm-svn: 303248
When it resolves symbol-only variables, the expression parser
currently looks only in the global module list. It should prefer
the current module.
I've fixed that behavior by making it search the current module
first, and only search globally if it finds nothing. I've also
added a test case.
After review, I moved the core of the lookup algorithm into
SymbolContext for use by other code that needs it.
Thanks to Greg Clayton and Pavel Labath for their help.
Differential Revision: https://reviews.llvm.org/D33083
llvm-svn: 303223
ptr_refs exposed a problem in ClangASTContext's implementation: it
uses an accessor to downcast a QualType to an
ObjCObjectPointerType, but the accessor is not fully general.
getAs() is the safer way to go.
I've added a test case that uses ptr_refs in a way that would
crash before the fix.
<rdar://problem/31363513>
llvm-svn: 303110
as described in pr33042, we cannot reliably retrieve the return value on
arm64 in cases it is returned via x8 pointer. I tried to do this as
surgically as possible and disabled it only on targets I know to be
affected, as the code is still useful, even though it can only work on
best-effort basis.
llvm-svn: 303076
The Timer destructor would grab a global mutex in order to update
execution time. Add a class to define a category once, statically; the
class adds itself to an atomic singly linked list, and thus subsequent
updates only need to use an atomic rather than grab a lock and perform a
hashtable lookup.
Differential Revision: https://reviews.llvm.org/D32823
Patch by Scott Smith <scott.smith@purestorage.com>.
llvm-svn: 303058
It was returning const std::string& which was leading to
unnecessary copies all over the place, and preventing people
from doing things like Dict->GetValueForKeyAsString("foo", ref);
llvm-svn: 302875
This renames the LLDB error class to Status, as discussed
on the lldb-dev mailing list.
A change of this magnitude cannot easily be done without
find and replace, but that has potential to catch unwanted
occurrences of common strings such as "Error". Every effort
was made to find all the obvious things such as the word "Error"
appearing in a string, etc, but it's possible there are still
some lingering occurences left around. Hopefully nothing too
serious.
llvm-svn: 302872
Templates can end in parameter packs, like this
template <class T...> struct MyStruct
{ /*...*/ };
LLDB does not currently support these parameter packs;
it does not emit them into the template argument list
at all. This causes problems when you specialize, e.g.:
template <> struct MyStruct<int>
{ /*...*/ };
template <> struct MyStruct<int, int> : MyStruct<int>
{ /*...*/ };
LLDB generates two template specializations, each with
no template arguments, and then when they are imported
by the ASTImporter into a parser's AST context we get a
single specialization that inherits from itself,
causing Clang's record layout mechanism to smash its
stack.
This patch fixes the problem for classes and adds
tests. The tests for functions fail because Clang's
ASTImporter can't import them at the moment, so I've
xfailed that test.
Differential Revision: https://reviews.llvm.org/D33025
llvm-svn: 302833
The find function in repo.py calls sys.exit on error. Without this import that
call to exit will fail, masking the actual error message. This patch fixes that.
llvm-svn: 302584
If we can't find the "is dyld locked" symbol, assume it is safe
to load the image unless we only have 1 image loaded - in which case
we are in _dyld_start and it is definitely NOT safe.
Also add a little better errors to that function, and better logging
in SBProcess.cpp.
<rdar://problem/30174817>
llvm-svn: 302327
These methods can be used by the derived expression types to perform expression
specific and/or language specific actions before and after the expression runs.
(ThreadPlanCallUserExpression is modified to call these methods on the
expression immediately before/after execution of the expression).
The immediate motivation is allowing Swift expressions to notify the swift
runtime that exclusivity enforcement should be suspended while the expression
runs (we want LLDB expressions to be able to access variables even when they're
considered exclusively owned by someone else in the original program).
Reviewed in https://reviews.llvm.org/D32889
llvm-svn: 302314
Some of the refactoring in r301492 broke UDP socket connections. This is a partial revert of that refactoring. At some point I'll spend more time diagnosing where the refactoring went wrong and how to better clean up this code, but I don't have time to do that today.
llvm-svn: 302282
Summary:
'arch' is a valid qHostInfo key, but the unit
test for qHostInfo did not include it in the set of possible keys.
Reviewers: tfiala, labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32711
llvm-svn: 302260
Summary:
I have found a way to segfault lldb in 7 keystrokes! Steps to reproduce:
1) Launch lldb
2) Type `print` and hit enter. lldb will now prompt you to type a list of
expressions, followed by an empty line.
3) Hit enter, indicating the end of your input.
4) Segfault!
After some investigation, I've found the issue in Host/common/Editline.cpp.
Editline::MoveCursor() relies on m_input_lines not being empty when the `to`
argument is CursorPosition::BlockEnd. This scenario, as far as I can tell,
occurs in one specific instance: In Editline::EndOrAddLineCommand() when the
list of lines being processed contains exactly one string (""). Meeting this
condition is fairly simple, I have posted steps to reproduce above.
Reviewers: krytarowski, zturner, labath
Reviewed By: labath
Subscribers: scott.smith, lldb-commits
Differential Revision: https://reviews.llvm.org/D32421
Patch by Alex Langford.
llvm-svn: 302225
Summary:
Many parallel tasks just want to iterate over all the possible numbers from 0 to N-1. Rather than enqueue N work items, instead just "map" the function across the requested integer space.
Reviewers: clayborg, labath, tberghammer, zturner
Reviewed By: clayborg, zturner
Subscribers: zturner, lldb-commits
Differential Revision: https://reviews.llvm.org/D32757
Patch by Scott Smith <scott.smith@purestorage.com>.
llvm-svn: 302223
Summary:
Arm64 Procedure Call Standard specifies than only vectors up to 16 bytes
are stored in v0 (which makes sense, as that's the size of the
register). 32-byte vector types are passed as regular structs via x8
pointer. Treat them as such.
This fixes TestReturnValue for arm64-clang. I also split the test case
into two so I can avoid the if(gcc) line, and annotate each test
instead. (It seems the vector type tests fail with gcc only when
targetting x86 arches).
Reviewers: tberghammer, eugene
Subscribers: aemerson, omjavaid, rengolin, srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D32813
llvm-svn: 302220
Jim Ingham