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
Summary:
This adds a couple of unit tests to the MainLoop class. To get the
kqueue based version of the signal handling passing, I needed to
modify the implementation a bit to make the queue object persistent.
Otherwise, only the signals which are send during the Run call would get
processed, which did not match the ppoll behaviour.
I also took the opportunity to remove the ForEach template functions and
replace them with something more reasonable.
Reviewers: beanz, eugene
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D32753
llvm-svn: 302133
Summary:
The existing cpp-level checks using PR_MPX_ENABLE_MANAGEMENT aren't sufficient,
as this isn't defined for linux kernel versions below 3.19.
Reviewers: valentinagiusti, zturner, labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32719
llvm-svn: 302027
gnuwin32 rm does not like wildcards that match nothing even if we
specify -f (probably because the wildcard expansion happens in-process
there). We could use make $(wildcard) here, but it seems safer to
explicitly list the files here, just like the normal Makefile.rules
does.
llvm-svn: 302013
Summary: It seems that if we have no context, then it can't possibly be a method. Check that first.
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D32708
Patch by Scott Smith <scott.smith@purestorage.com>.
llvm-svn: 302008
Summary:
If we have symbol information in a separate file, we need to be very
careful about presenting a unified section view of module to the rest of
the debugger. ObjectFileELF had code to handle that, but it was being
overly cautious -- the section->GetFileSize()!=0 meant that the
unification would fail for sections which do not occupy any space in the
object file (e.g., .bss). In my case, that manifested itself as not
being able to display the values of .bss variables properly as the
section associated with the variable did not have it's load address set
(because it was not present in the unified section list).
I test this by making sure the unified section list and the variables
refer to the same section.
Reviewers: eugene, zturner
Subscribers: tberghammer, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D32434
llvm-svn: 301917
Summary:
UniqueCStringMap "sorts" the entries for fast lookup, but really it only cares about uniqueness. ConstString can be compared by pointer alone, rather than with strcmp, resulting in much faster comparisons. Change the interface to take ConstString instead, and propagate use of the type to the callers where appropriate.
Reviewers: #lldb, clayborg
Reviewed By: clayborg
Subscribers: labath, jasonmolenda, lldb-commits
Differential Revision: https://reviews.llvm.org/D32316
Patch by Scott Smith <scott.smith@purestorage.com>.
llvm-svn: 301908
Summary: It is simply unused, and the header for it is private, so there should be no external dependencies.
Reviewers: #lldb, zturner
Reviewed By: zturner
Subscribers: zturner, tberghammer, jingham, lldb-commits
Differential Revision: https://reviews.llvm.org/D32503
Patch by Scott Smith <scott.smith@purestorage.com>.
llvm-svn: 301903
Summary: ConstStrings are immutable, so there is no need to grab even a reader lock in order to read the length field.
Reviewers: #lldb, labath
Reviewed By: labath
Subscribers: zturner, labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D32306
Patch by Scott Smith <scott.smith@purestorage.com>
llvm-svn: 301642
Summary:
It turns out that even though ppoll is available on all the android
devices we support, it does not seem to be working properly on all of
them -- MainLoop just does a busy loop with ppoll returning EINTR and
not making any progress.
This brings back the pselect implementation and makes it available on
android. I could not do any cmake checks for this as the ppoll symbol is
actually avaiable -- it just does not work.
Reviewers: beanz, eugene
Subscribers: srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D32600
llvm-svn: 301636
Loading a shared library can require a large amount of work; rather than do that serially for each library,
this patch will allow parallelization of the symbols and debug info name indexes.
From scott.smith@purestorage.comhttps://reviews.llvm.org/D32598
llvm-svn: 301609
This just adds a comment to SocketAddress about it being used by debugserver and the implications of that.
If we need to make changes to this class that make it unsuitable for debugserver we can re-implement the minimal abstractions we need from this file in debugserver. I would prefer not to do that because code duplication is bad. Nuff said.
llvm-svn: 301580
This updates the regular expression used to match host/port pairs for the gdb-remote command to also match IPv6 addresses.
The IPv6 address matcher is very generic and does not really check for structural validity of the address. It turns out that IPv6 addresses are very complicated.
llvm-svn: 301559
This patch abstracts the generation of Config.h and creates a dummy project entry point to allow generation of LLDB's Config header without performing a full CMake configuration.
This will enable the Xcode project to generate LLDB's Config header.
llvm-svn: 301553
before r301492, we could specify "*:1234" as an address to lldb-server
and it would interpret that as "any". I am not sure that's a good idea,
but we have usages of that in the test suite, and without this the
remote test suite fails.
I'm adding that back, as it does not seem it was an intended side-effect
of that change, but I am open to removing it in the future, after
discussion and test suite fixup.
llvm-svn: 301534
Summary:
LLVM r300140 changed the layout and field names of __compressed_pair, which
broke LLDB's std::vector, std::map and std::unsorted_map formatters.
This patch attempts to fix these formatters by having them interogate the
__compressed_pair values to determine whether they're pre- or post-r300140
variants, then access them accordingly.
Reviewers: jingham, EricWF
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D32554
llvm-svn: 301493
This support was landed in r300579, and reverted in r300669 due to failures on the bots.
The failures were caused by sockets not being properly closed, and this updated version of the patches should resolve that.
Summary from the original change:
This patch adds IPv6 support to LLDB/Host's TCP socket implementation. Supporting IPv6 involved a few significant changes to the implementation of the socket layers, and I have performed some significant code cleanup along the way.
This patch changes the Socket constructors for all types of sockets to not create sockets until first use. This is required for IPv6 support because the socket type will vary based on the address you are connecting to. This also has the benefit of removing code that could have errors from the Socket subclass constructors (which seems like a win to me).
The patch also slightly changes the API and behaviors of the Listen/Accept pattern. Previously both Listen and Accept calls took an address specified as a string. Now only listen does. This change was made because the Listen call can result in opening more than one socket. In order to support listening for both IPv4 and IPv6 connections we need to open one AF_INET socket and one AF_INET6 socket. During the listen call we construct a map of file descriptors to addrin structures which represent the allowable incoming connection address. This map removes the need for taking an address into the Accept call.
This does have a change in functionality. Previously you could Listen for connections based on one address, and Accept connections from a different address. This is no longer supported. I could not find anywhere in LLDB where we actually used the APIs in that way. The new API does still support AnyAddr for allowing incoming connections from any address.
The Listen implementation is implemented using kqueue on FreeBSD and Darwin, WSAPoll on Windows and poll(2) everywhere else.
https://reviews.llvm.org/D31823
llvm-svn: 301492
This code really doesn't make any sense: there is only ever one InputKind here.
Plus, this is an incomplete and out-of-date copy-paste of some Clang code. This
really ought to be revisited, but this change should get the bots green again.
llvm-svn: 301483
I've filed a bug covering better unit testing of our runtime metadata reader, which will allow this to be testable..
<rdar://problem/31793264>
llvm-svn: 301461
ValueObject methods.
Using ArrayRef allows us to remove some overloads, work with more array-like
types, and avoid some std::vector temporaries.
https://reviews.llvm.org/D32518
llvm-svn: 301441
Summary:
This patch introduces new SB APIs for tracing support
inside LLDB. The idea is to gather trace data from
LLDB and provide it through this APIs to external
tools integrating with LLDB. These tools will be
responsible for interpreting and presenting the
trace data to their users.
The patch implements the following new SB APIs ->
-> StartTrace - starts tracing with given parameters
-> StopTrace - stops tracing.
-> GetTraceData - read the trace data .
-> GetMetaData - read the meta data assosciated with the trace.
-> GetTraceConfig - read the trace configuration
Tracing is associated with a user_id that is returned
by the StartTrace API and this id needs to be used
for accessing the trace data and also Stopping
the trace. The user_id itself may map to tracing
the complete process or just an individual thread.
The APIs require an additional thread parameter
when the user of these APIs wishes to perform
thread specific manipulations on the tracing instances.
The patch also includes the corresponding
python wrappers for the C++ based APIs.
Reviewers: k8stone, lldb-commits, clayborg
Reviewed By: clayborg
Subscribers: jingham, mgorny
Differential Revision: https://reviews.llvm.org/D29581
llvm-svn: 301389
Summary:
The toolchain file has been deprecated in favor of the "official"
toolchain file present in the Android NDK. Also update the web
build instructions to reflect this.
Reviewers: eugene
Subscribers: srhines, mgorny, dgross, tberghammer, lldb-commits
Differential Revision: https://reviews.llvm.org/D32441
llvm-svn: 301306
Many times a user wants to access a type when there's a variable of
the same name, or a variable when there's a type of the same name.
Depending on the precise context, currently the expression parser
can fail to resolve one or the other.
This is because ClangExpressionDeclMap has logic to limit the
amount of information it searches, and that logic sometimes cuts
down the search prematurely. This patch removes some of those early
exits.
In that sense, this patch trades performance (early exit is faster)
for correctness.
I've also included two new test cases showing examples of this
behavior – as well as modifying an existing test case that gets it
wrong.
llvm-svn: 301273
LLDB uses clang::DeclContexts for lookups, and variables get put into
the DeclContext for their abstract origin. (The abstract origin is a
DWARF pointer that indicates the unique definition of inlined code.)
When the expression parser is looking for variables, it locates the
DeclContext for the current context. This needs to be done carefully,
though, e.g.:
__attribute__ ((always_inline)) void f(int a) {
{
int b = a * 2;
}
}
void g() {
f(3);
}
Here, if we're stopped in the inlined copy of f, we have to find the
DeclContext corresponding to the definition of f – its abstract
origin. Clang doesn't allow multiple functions with the same name and
arguments to exist. It also means that any variables we see must be
placed in the appropriate DeclContext.
[Bug 1]: When stopped in an inline block, the function
GetDeclContextDIEContainingDIE for that block doesn't properly
construct a DeclContext for the abstract origin for inlined
subroutines. That means we get duplicated function DeclContexts, but
function arguments only get put in the abstract origin's DeclContext,
and as a result when we try to look for them in nested contexts they
aren't found.
[Bug 2]: When stopped in an inline block, the DWARF (for space
reasons) doesn't explicitly point to the abstract origin for that
block. This means that the function GetClangDeclContextForDIE returns
a different DeclContext for each place the block is inlined. However,
any variables defined in the block have abstract origins, so they
will only get placed in the DeclContext for their abstract origin.
In this fix, I've introduced a test covering both of these issues,
and fixed them.
Bug 1 could be resolved simply by making sure we look up the abstract
origin for inlined functions when looking up their DeclContexts on
behalf of nested blocks.
For Bug 2, I've implemented an algorithm that makes the DeclContext
for a block be the containing DeclContext for the closest entity we
would find during lookup that has an abstract origin pointer. That
means that in the following situation:
{ // block 1
int a;
{ // block 2
int b;
}
}
if we looked up the DeclContext for block 2, we'd find the block
containing the abstract origin of b, and lookup would proceed
correctly because we'd see b and a. However, in the situation
{ // block 1
int a;
{ // block 2
}
}
since there isn't anything to look up in block 2, we can't determine
its abstract origin (and there is no such pointer in the DWARF for
blocks). However, we can walk up the parent chain and find a, and its
abstract origin lives in the abstract origin of block 1. So we simply
say that the DeclContext for block 2 is the same as the DeclContext
for block 1, which contains a. Lookups will return the same results.
Thanks to Jim Ingham for review and suggestions.
Differential revision: https://reviews.llvm.org/D32375
llvm-svn: 301263
The revison https://reviews.llvm.org/D32125 will fixed the off_t for GNU specific 32 bit platform. This fixed the difference in definition of off_t in LLDB and LLVM
Subscribers: jaydeep, bhushan, lldb-commits, slthakur, llvm-commits, krytarowski, emaste, zturner
llvm-svn: 301172
Summary:
the reason for this is two-fold:
- getaddrinfo without the extra arguments will return the same
(network-level) address multiple times, once for each supported
transport protocol, which is not what is usually intended (it certainly
wasn't in D31823)
- it enables us to rewrite the getaddrinfo member function in terms of
the static GetAddressInfo function.
Reviewers: beanz, tberghammer
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32357
llvm-svn: 301168
Removes Clang warning ThreadSanitizerRuntime.cpp:591:21: warning:
comparison of integers of different signs: 'int' and 'size_t' (aka
'unsigned long') [-Wsign-compare]
llvm-svn: 301067
Sometimes you are debugging in source, but you really only want to see
the disassembly. That's easy to do but you have to set a few variables.
This command toggles between your old values, and a disassembly only mode.
llvm-svn: 300902
Summary:
MergeFrom was updating the architecture if the target triple did not
have it set. However, it was leaving the core field as invalid. This
resulted in assertion failures in core file tests as a missing core
meant we were unable to compute the address byte size properly.
Add a unit test for the new behaviour.
Reviewers: jingham, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32221
llvm-svn: 300836
The test fails because an older clang did not emit the required debug
info (I am not sure when this got added, but clang-3.7 certainly did not
work yet). The actual platform has nothing to do with this.
llvm-svn: 300834
I thought my previous commit got the last ones but somehow I missed
these. This also resurrects TestDataFormatterLibcxxSet, which got
commented out in r263859 as a part of some seemingly unrelated change.
llvm-svn: 300833
Summary:
The runtime discovers contexts through RenderScriptRuntime::Capture*()
methods. These methods see the low-level context representation.
However, the runtime calls APIs that require the high-level context
representation. Therefore, it needs to call yet another API to find
the high-level representation associated with a given low-level
representation.
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32184
llvm-svn: 300727
Clang rejects __attribute__((regparm)) when targetting arm. The default
calling convention passes arguments in registers anyway, so we can just
remove them in this case.
llvm-svn: 300670
The break the linux bots (and probably any other machine which would
run the test suite in a massively parallel way). The problem is that it
can happen that we only successfully create an IPv6 listening socket
(because the relevant IPv4 port is used by another process) and then the
connecting side attempts to connect to the IPv4 port and fails.
It's not very obvious how to fix this problem, so I am reverting this
until we come up with a solution.
llvm-svn: 300669
This is not ideal, but it should get the bot going again. I'll need to revisit this if we want to get signal handling working on Windows.
llvm-svn: 300587
Summary: This patch adds IPv6 support to debugserver. It follows a similar pattern to the changes proposed for LLDB/Host except that the listen implementation is only with kqueue(2) because debugserver is only supported on Darwin.
Reviewers: jingham, jasonmolenda, clayborg
Reviewed By: clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D31824
llvm-svn: 300580
Summary:
This patch adds IPv6 support to LLDB/Host's TCP socket implementation. Supporting IPv6 involved a few significant changes to the implementation of the socket layers, and I have performed some significant code cleanup along the way.
This patch changes the Socket constructors for all types of sockets to not create sockets until first use. This is required for IPv6 support because the socket type will vary based on the address you are connecting to. This also has the benefit of removing code that could have errors from the Socket subclass constructors (which seems like a win to me).
The patch also slightly changes the API and behaviors of the Listen/Accept pattern. Previously both Listen and Accept calls took an address specified as a string. Now only listen does. This change was made because the Listen call can result in opening more than one socket. In order to support listening for both IPv4 and IPv6 connections we need to open one AF_INET socket and one AF_INET6 socket. During the listen call we construct a map of file descriptors to addrin structures which represent the allowable incoming connection address. This map removes the need for taking an address into the Accept call.
This does have a change in functionality. Previously you could Listen for connections based on one address, and Accept connections from a different address. This is no longer supported. I could not find anywhere in LLDB where we actually used the APIs in that way. The new API does still support AnyAddr for allowing incoming connections from any address.
The Listen implementation is implemented using kqueue on FreeBSD and Darwin, WSAPoll on Windows and poll(2) everywhere else.
Reviewers: zturner, clayborg
Subscribers: jasonmolenda, labath, lldb-commits, emaste
Differential Revision: https://reviews.llvm.org/D31823
llvm-svn: 300579
r285226 dropped the code that did these checks. I am pretty
sure that was inadvertent, so I added that back in and added
a test for it.
<rdar://problem/31661252>
llvm-svn: 300564
Pavel Labath