Some repos are not git repos, so git is expected
to fail. These errors should not go to stderr,
because Xcode interprets them as failures.
llvm-svn: 296924
In an effort to move the various DataBuffer / DataExtractor
classes from Core -> Utility, we have to separate the low-level
functionality from the higher level functionality. Only a
few functions required anything other than reading/writing
raw bytes, so those functions are separated out into a
more appropriate area. Specifically, Dump() and DumpHexBytes()
are moved into free functions in Core/DumpDataExtractor.cpp,
and GetGNUEHPointer is moved into a static function in the
only file that it's referenced from.
Differential Revision: https://reviews.llvm.org/D30560
llvm-svn: 296910
All references to Host and Core have been removed, so this
class can now safely be lowered into Utility.
Differential Revision: https://reviews.llvm.org/D30559
llvm-svn: 296909
Prior to MSVC 2015 we had to manually include this header any
time we were going to include <thread> or <future> due to a
bug in MSVC's STL implementation. This has been fixed in MSVC
for some time now, and we require VS 2015 minimum, so we can
remove this across all subprojects.
llvm-svn: 296906
$(realpath), which I guess is a make builtin, gives strange results on
Windows. $(shell realpath) invokes the gnuwin external binary, which
works correctly.
llvm-svn: 296876
Make sure we don't generate extremely long file names for test trace log
file, as this can cause path-too-long errors. As the compilers in the
android ndk are deeply nested, it's very easy to trigger these.
I chose to output at most 4 path components -- this should keep the full
path for common cases like /usr/bin/gcc with room to spare, and should
be enough to uniquely identify the compiler for more deeply nested
cases.
llvm-svn: 296870
Summary:
This teaches the test makefiles about the Android NDK, so we are able to
run the tests without first going through the make_standalone_toolchain
script. The motivation for this is the ability to run both libc++ and
libstdc++ tests together, which previously was not possible because
make_standalone_toolchain bakes in the STL to use during toolchain
creation time. The support for this is not present yet -- this change
only make sure we don't regress for existing funcionality (gcc w/
libstdc++). Clang and libc++ support will be added later.
I've checked that the mips android targets compile after this change,
but I have no way of checking whether this breaks anything. If you are
reading this and it broke you, let me know.
Reviewers: tberghammer, danalbert
Subscribers: srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D30410
llvm-svn: 296869
Summary:
It does not change members or call non-const members.
HostInfo::GetArchitecture() returns a const object ref (maybe others?),
which can't access the non-const function.
Reviewers: labath, eugene
Reviewed By: labath, eugene
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30515
Author: Jason Majors <jmajors@google.com>
llvm-svn: 296868
This in turn triggered some fallout where other files had
been transitively picking up includes that they needed from
FileSpec.h, so I've fixed those up as well.
llvm-svn: 296855
This was a list that I've had kicking around for a while, and would
add to whenever some hallway conversation would bring up another good
idea. It's not doing any good on my desktop, but it might generate
some inspiration here. Please add to this if you have any other
good ideas.
I apologize for the formatting, but if I wait to get it looking
nice it would probably stay on my desktop.
llvm-svn: 296814
this test was using the VPATH hack to avoid having a copy of the
inferior source code. This makes the test fail if in happens to run
concurrently with a test in the parent folder. Fix that by moving it up
to the parent.
llvm-svn: 296741
MSVC (at least the version I am using) does not want to implicitly
capture a const bool variable. Move it into the lambda, as it is not
used outside anyway.
llvm-svn: 296738
Summary:
The test runner has code to autodetect this, but it's not very smart --
in particular, it fails in the case where we build the test executables
with the just-built clang. Since cmake already has the knowledge about
the right toolchain, we can just have it pass the appropriate flags to
the test runner.
This also removes the "temporary" cache-scrubbing hack added a couple
months ago.
Reviewers: zturner, beanz
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D30453
llvm-svn: 296593
Summary:
Use StringRef and ArrayRef where possible. This adds an accessor to the
Args class to get a view of the arguments as ArrayRef<const char *>.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30402
llvm-svn: 296592
Summary:
Native Thread ID is retrieved with _lwp_self() on NetBSD.
The returned value is of type int32_t, but for consistency with other Operating Systems cast it to uint64_t.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, labath, clayborg, emaste
Reviewed By: labath, clayborg
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D30374
llvm-svn: 296360
Summary:
These two register contexts were identical, so this shouldn't cause any
regressions, but I'd appreciate it if you can check that this at least compiles.
Reviewers: emaste, sas
Subscribers: aemerson, rengolin, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27126
llvm-svn: 296335
load_size should be 64-bit unconditionally to match the underlying API.
This makes sure the MAX value correctly signals to auto-detect the file
size when mmap()ing.
llvm-svn: 296334
The channel refactor introduced a regression where we were not honoring
the log options passed when enabling the channel. Fix that and add a
test.
llvm-svn: 296329
Summary:
There is nothing we can do with the breakpoint once the associated
target becomes deleted. This will make sure we don't hold on to more
resources than we need in this case. In particular, this fixes the case
TestStepOverBreakpoint on windows, where a lingering SBBreakpoint object
causes us to nor unmap the executable file from memory.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30249
llvm-svn: 296328
match but the 'is_regex' argument was not passed as true. Not sure
this is causing a bug, but noticed it while working on another bug.
These formatters gained a regex in r274489 for NDK but didn't pick
up the is_regex flag at the time.
<rdar://problem/30646077>
llvm-svn: 296243
After a series of patches on the LLVM side to get the mmaping
code up to compatibility with LLDB's needs, it is now ready
to go, which means LLDB's custom mmapping code is redundant.
So this patch deletes it all and uses LLVM's code instead.
In the future, we could take this one step further and delete
even the lldb DataBuffer base class and rely entirely on
LLVM's facilities, but this is a job for another day.
Differential Revision: https://reviews.llvm.org/D30054
llvm-svn: 296159
Summary: QPassSignals package allows lldb client to tell lldb-server to ignore certain types of signals and re-inject them back to inferior without stopping execution.
Reviewers: jmajors, labath
Subscribers: danalbert, srhines, emaste, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D30286
Author: Eugene Zemtsov <ezemtsov@google.com>
llvm-svn: 296101
acquired only after checking if the ivar shared pointer was already
filled in. But when I assign an UnwindPlan object to the shared
pointer, I assign an empty object and then fill it in. That leaves
a window where another thread could get the shared pointer to the
empty (but quickly being-filled-in) object and lead to a crash.
Also two changes from Greg for correctness on the TestMultipleDebuggers
test case.
<rdar://problem/30564102>
llvm-svn: 296084
Summary:
NetBSD 7.99.62 introduced Debug Registers interface similar to the FreeBSD one.
This interface will land NetBSD-8.0.
Introduce support for this interface in Register Context NetBSD x86_64 unconditionally as older versions of NetBSD will not be supported.
This change allows to reduce diff with other ports and remove local copy of the RegisterInfos_x86_64.h content.
NetBSD Register Context for 32-bit x86 support will be added later.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, joerg, emaste, clayborg
Reviewed By: labath, clayborg
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D30287
llvm-svn: 296071
Summary:
NetBSD 8.0 will ship with accept4(2) in libc wrapping paccept(2).
This change reduces needless difference with other platforms.
Older versions of NetBSD will not be supported.
No functional change.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, emaste, labath, clayborg
Reviewed By: emaste, labath, clayborg
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D30288
llvm-svn: 296070
Summary:
This also removes magic rename code, which caused the channel to be
called "linux" when built on a linux machine, and "freebsd" when built
on a freebsd one, which seems unnecessary - registering a new channel is
sufficiently simple now that if we wish to log something extremely
os-specific, we can just create a new channel. None of the current
categories seem very specific to one OS or another.
Reviewers: emaste, krytarowski
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30250
llvm-svn: 295954
Summary:
When lldb-server is started with the -P <port> or -m/-M <min/max port> options to specify which ports are available for remote connections the child debug server is told what port it should listen on. In those cases lldb-server needs to wait for the child to report it’s port number as otherwise it can tell the lldb client that the child is up and listening before it is actually listening on that port. lldb-server already waits in the cases where a port wasn’t specified by waiting until the child reports the port it is using. It was skipping this synchronisation step when passed a port numbers as it knew what the port would be however it does need to ensure the child process has had time to open that port and waiting until the child reports the port number makes sure this has happened.
This patch just removes the one case where a child was spawned and lldb-server did not wait for it to report it’s port number before telling the client lldb process the child is ready to connect to.
This issue was discussed on lldb-dev in a thread here:
http://lists.llvm.org/pipermail/lldb-dev/2017-February/012002.html
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30255
llvm-svn: 295947
LLDB has many branches in a variety of repositories.
The build-script.py file is subtly different for each set.
This is unnecessary and causes merge headaches.
This patch makes build-llvm.py consult a directory full
of .json files, each one of which matches a particular
branch using a regular expression.
This update to the patch introduces a FALLBACK file
whose contents take precedence if the current branch
could not be identified. If the current branch could be
identified, FALLBACK is updated, allowing the user to
e.g. cut branches off of known branches and still have
the automatic checkout mechanism work.
It also documents all of this.
Differential revision: https://reviews.llvm.org/D30275
llvm-svn: 295922
- Allow zero byte size request for memory and ensure it gets a unique address
- Exit the free block loop when we find an appropriate free block
<rdar://problem/30644888>
llvm-svn: 295907
LLDB has many branches in a variety of repositories.
The build-script.py file is subtly different for each set.
This is unnecessary and causes merge headaches.
This patch makes build-llvm.py consult a directory full
of .json files, each one of which matches a particular
branch using a regular expression.
Differential revision: https://reviews.llvm.org/D30275
llvm-svn: 295897
Summary:
The main difference here is that in the WINLOG macros you can specify
log categories per call, whereas here you have to go the usual lldb
route of getting a Log* variable first. While this means you have to
write at least two statements, it usually means that each statement will
fit on a single line, whereas fitting the WINLOG invocation on a single
line was almost impossible. So the total size of code does not increase
even in functions with a single log statement, and functions with more
logging get shorter.
The downside here is reduced flexibility in specifying the log
categories, which a couple of functions used quite heavily (e.g.
RefreshStateAfterStop). For these I chose a single category used most
prominently and put everything into that, although a solution with
multiple log variables is definitely possible.
Reviewers: zturner, amccarth
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30172
llvm-svn: 295822
Summary:
The code was attempting to copy the shared pointer member in order to
guarantee atomicity, but this is not enough. Instead, protect the
pointer with a proper read-write mutex.
This bug was present here for a long time, but my recent refactors must
have altered the timings slightly, such that now this fails fairly often
when running the tests: the test runner runs the "log disable" command
just as the thread monitoring the lldb-server child is about to report
that the server has exited.
I add a test case for this. It's not possible to reproduce the race
deterministically in normal circumstances, but I have verified that
before the fix, the test failed when run under tsan, and was running
fine afterwards.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30168
llvm-svn: 295712
Summary:
I originally set out to move the NameMatches closer to the relevant
function and add some unit tests. However, in the process I've found a
couple of bugs in the implementation:
- the early exits where not always correct:
- (test==pattern) does not mean the match will always suceed because
of regular expressions
- pattern.empty() does not mean the match will fail because the "" is
a valid prefix of any string
So I cleaned up those and added some tests. The only tricky part here
was that regcomp() implementation on darwin did not recognise the empty
string as a regular expression and returned an REG_EMPTY error instead.
The simples fix here seemed to be to replace the empty expression with
an equivalent non-empty one.
Reviewers: clayborg, zturner
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D30094
llvm-svn: 295651
Use both LLDB- and LLVM-specific tool/library directories when LLDB is
being built stand-alone. This ensures that the freshly-built tools
(and libraries) are used correctly.
Without this patch, the test suite uses LLVM_TOOLS_DIR and LLVM_LIBS_DIR
to locate lldb, and set PATH and LD_LIBRARY_PATH. When doing
a stand-alone build, these variables represent the installed LLVM.
As a result, tests either fail due to missing lldb executable
or use an earlier installed LLDB version rather than the one being
built.
To solve this, additional LLDB_TOOLS_DIR and LLDB_LIBS_DIR variables
are added and populated using LLVM_*_OUTPUT_INTDIR. Those variables
contain directories used to output built executables and libraries.
In stand-alone builds, they represent the build-tree directories
used by LLDB. In integrated builds, they have the same values as
LLVM_*_DIR and therefore using them does not harm.
The new variables are prepended to PATH and LD_LIBRARY_PATH to ensure
that freshly built binaries are preferred over potentially earlier
installed ones. Furthermore, paths used to locate various tools are
updated to match appropriate locations.
Differential Revision: https://reviews.llvm.org/D29985
llvm-svn: 295621
unittest/Utility to unittest/Target so the unit
tests can be run from xcode again.
The diff is enormous - I think zachary might have
put windows line endings or something with his last
commit? didn't look too closely but his commit & this
commit have every line being different.
llvm-svn: 295530
The testsuite's results formatter maintains a result_status_counts
structure solely for the purpose of setting the return status code
after the testsuite has run. This data is redundant with the
result_events structure that contains the results of individual
tests.
There are subtle bugs arising from this redundancy that make some
builds report no errors but a nonzero status. Rather than try to
make sure these two are always in agreement, I've just rewritten
the code that used to use the counts to now use the per-test
results.
<rdar://problem/30496966>
llvm-svn: 295522
Summary:
There have been a few new values added to a few LLVM enums
this change makes sure that LLDB code handles them correctly.
Reviewers: labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D30005
Author: Eugene Zemtsov <ezemtsov@google.com>
llvm-svn: 295445
The way of injecting an error into the printf call was not working on
darwin - the C library still happily format the character. It only
returns an error after we use a wide character that does not fit into a
single byte, so switch the test to use that.
llvm-svn: 295443
Changes wrt. previous version:
- add #include <atomic>: fix build on windows
- add extra {} around the string literals used to initialize
llvm::StringLiteral: fix gcc build
llvm-svn: 295442
In the case we are stepping over the thread creation instruction, we
will end up calling Thread::SingleStep back-to-back twice (because of
the intermediate PTRACE_EVENT_CLONE stop). This will cause the cpu mask
to be set inappropriately (because the old SingleStepCheck object will
be destroyed after we create the new one), and the single-step will
fail.
Before the refactor the code was still incorrect in this case, but in a
different way (the thread was left with the incorrect mask after the
stepping was complete), so this was not easy to spot.
This fixes TestCreateDuringInstructionStep on the affected devices.
llvm-svn: 295440
While refactoring the code in r293046 I made a very basic error -
relying on destructor side-effects of a copyable object. Fix that and
make the object non-copyable.
This fixes the tests on the platforms that need this workaround, but
unfortunately we don't have a way to make a more platform-agnostic test
right now.
llvm-svn: 295345
TSan now has the ability to report races on "external" object, i.e. any library class/object that has read-shared write-exclusive threading semantics. The detection and reporting work almost out of the box, but TSan can now provide the type of the object (as a string). This patch implements this into LLDB.
Differential Revision: https://reviews.llvm.org/D30024
llvm-svn: 295342
effects was passed as an expression to assert() calls. If lldb is
built without asserts, the expression was eliminated and we lost
the side effects -- these methods stopped working.
<rdar://problem/30342959>
llvm-svn: 295271
Summary:
We currently have two log channel registration mechanisms. One uses a
set of function pointers and the other one is based on the
PluginManager.
The PluginManager dependency is unfortunate, as logging
is also used in lldb-server, and the PluginManager pulls in a lot of
classes which are not used in lldb-server.
Both approach have the problem that they leave too much to do for the
user, and so the individual log channels end up reimplementing command
line argument parsing, category listing, etc.
Here, I replace the PluginManager-based approach with a one. The new API
is more declarative, so the user only needs to specify the list of list
of channels, their descriptions, etc., and all the common tasks like
enabling/disabling categories are hadled by common code. I migrate the
LogChannelDWARF (only user of the PluginManager method) to the new API.
In the follow-up commits I'll replace the other channels with something
similar.
Reviewers: clayborg, zturner, beanz
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D29895
llvm-svn: 295190
Summary:
It turns out listing each library twice is not enough to resolve all
references in a debug build on linux - a number of executables fails to
link with random symbols missing. Increasing the number to three seems
to be enough. The choice of lldbCore to set the multiplicity on is
somewhat arbitrary, but it seems fitting, as it is the biggest layering
transgressor.
Reviewers: beanz
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D29888
llvm-svn: 295189
Summary:
GCC emits also symbols for the __PRETTY_FUNCTION__ virtual variable,
which we accidentaly pick up when looking for functions for with
"unique_function_name" in the name. This makes the target.FindFunctions
call fail, as that symbol is not a function.
I also strenghten the test a bit to make sure we actually find all the
functions we are interested in. I've put a check that we find at least 6
functions, but maybe this should be *exactly* 6 ?
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D29932
llvm-svn: 295170
Tim Hammerquist