| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The x86 FPR struct was defined as a struct containing a union between
two members: XSAVE and FXSAVE. This patch makes FPR a union directly to
remove one layer of indirection when trying to access the members.
The initial layout of these two structs is identical, which is
recognised by the fact that XSAVE has FXSAVE as its first member, so we
also considered removing one more layer and leave FPR identical to XSAVE
struct, but stopped short of doing that, as the FPR may be used to store
different layouts in the future (e.g., ones generated by the FSAVE
instruction).
Reviewers: clayborg, krytarowski
Subscribers: emaste, lldb-commits
Differential Revision: https://reviews.llvm.org/D41245
llvm-svn: 320966
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
lldb-server was sending the "exit" packet (W??) twice. This happened
because it was handling both the pre-exit (PTRACE_EVENT_EXIT) and
post-exit (WIFEXITED) as exit events. We had some code which was trying
to detect when we've already sent the exit packet, but this stopped
working quite a while ago.
This never really caused any problems in practice because the client
automatically closes the connection after receiving the first packet, so
the only effect of this was some warning messages about extra packets
from the lldb-server test suite, which were ignored because they didn't
fail the test.
The new test suite will be stricter about this, so I fix this issue
ignoring the first event. I think this is the correct behavior, as the
inferior is not really dead at that point, so it's premature to send the
exit packet.
There isn't an actual test yet which would verify the exit behavior, but
in my next patch I will add a test which will also test this
functionality.
Reviewers: eugene
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D41069
llvm-svn: 320961
|
|
|
|
|
|
|
|
| |
<rdar://problem/28725399>
Differential Revision: https://reviews.llvm.org/D41312
llvm-svn: 320952
|
|
|
|
|
|
| |
Fixes a few failured on the testsuite with CMake.
llvm-svn: 320891
|
|
|
|
|
|
|
|
|
|
| |
"Default" is a valid QoS for a thread on older versions of macOS,
like the one installed in the bot.
Thanks to Jason Molenda for helping me figuring out the problem.
<rdar://problem/28346273>
llvm-svn: 320883
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This makes StopReply class abstract, so that we can represent different
types of stop replies such as StopReplyStop and StopReplyExit (there
should also be a StopReplySignal, but I don't need that right now so I
haven't implemented it yet).
This prepares the ground for a new test I'm writing.
Reviewers: eugene, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D41067
llvm-svn: 320820
|
|
|
|
|
|
| |
cast to size_t to avoid narrowing error.
llvm-svn: 320816
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We use the llvm decompressor to decompress SHF_COMPRESSED sections. This enables
us to read data from debug info sections, which are sometimes compressed,
particuarly in the split-dwarf case. This functionality is only available if
llvm is compiled with zlib support.
Reviewers: clayborg, zturner
Subscribers: emaste, mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D40616
llvm-svn: 320813
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Adding a new test would require one to duplicate a significant part of
the existing test that we have. This attempts to reduce that by moving
some part of that code to the test fixture. The StandardStartupTest
fixture automatically starts up the server and connects it to the
client. I also add a more low-level TestBase fixture, which allows one
to start up the client and server in a custom way (I am going to need
this for the test I am writing).
Reviewers: eugene, zturner
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D41066
llvm-svn: 320809
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang recently switched to C++14 (with GNU extensions) as the default
dialect, but LLDB didn't catch up. This causes failures as LLDB still
evaluates ObjectiveC expressions as Objective C++ using C++98 as standard.
There are things not available in C++98, including, e.g. nullptr.
In some cases Objective-C `nil` is defined as `nullptr` so this causes
an evaluation failure. Switch the default to overcome this issue
(actually, currently lldb evaluates both C++11 and C++14 as C++11,
but that seems a larger change and definitely could be re-evaluated
in the future).
No test as this is currently failing on the LLDB bots after the clang
switch (so, de facto, there's a test already for it).
This is a recommit, with a thinko fixed (the code was previously
placed incorrectly).
<rdar://problem/36011995>
llvm-svn: 320778
|
|
|
|
|
|
|
| |
Some ubuntu bots are failing with this patch in, let me unblock
while I investigate.
llvm-svn: 320769
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang recently switched to C++14 (with GNU extensions) as the default
dialect, but LLDB didn't catch up. This causes failures as LLDB still
evaluates ObjectiveC expressions as Objective C++ using C++98 as standard.
There are things not available in C++98, including, e.g. nullptr.
In some cases Objective-C `nil` is defined as `nullptr` so this causes
an evaluation failure. Switch the default to overcome this issue
(actually, currently lldb evaluates both C++11 and C++14 as C++11,
but that seems a larger change and definitely could be re-evaluated
in the future).
No test as this is currently failing on the LLDB bots after the clang
switch (so, de facto, there's a test already for it).
<rdar://problem/36011995>
llvm-svn: 320761
|
|
|
|
| |
llvm-svn: 320759
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These two functions were calling each other, while handling different
branches of the if(IsInMemory()). This had a reason at some point in the
past, but right now it's just confusing.
I resolve this by removing the MemoryMapSectionData function and
inlining the !IsInMemory branch into ReadSectionData. There isn't
anything mmap-related in this function anyway, as the decision whether
to mmap is handled at a higher level.
This is a preparatory step to make ObjectFileELF be able to decompress
compressed sections (I want to make sure that all calls reading section
data are routed through a single piece of code).
Reviewers: clayborg
Subscribers: emaste, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D41169
llvm-svn: 320705
|
|
|
|
|
|
|
|
| |
A similar error message is printed again in lldb-gdbserver.cpp, so the
user will see the message twice. Also, this is generic library code, we
shouldn't really be using stderr here.
llvm-svn: 320704
|
|
|
|
|
|
|
|
| |
Found by the ubsan build.
<rdar://problem/31106358>
llvm-svn: 320541
|
|
|
|
|
|
|
|
|
| |
This fixes a previously introduced thinko, now that I have
a better idea of what's going on :)
<rdar://problem/35941757>
llvm-svn: 320540
|
|
|
|
|
|
|
|
|
| |
This is needed to ensure that the distribution and install-distribution
targets work properly.
Differential Revision: https://reviews.llvm.org/D41144
llvm-svn: 320537
|
|
|
|
|
|
|
| |
Add in a missing #include that AppleClang-900 complains about when
building with -DLLVM_ENABLE_MODULES.
llvm-svn: 320522
|
|
|
|
|
|
| |
This unbreaks the lldb modules build (-DLLVM_ENABLE_MODULES=On).
llvm-svn: 320456
|
|
|
|
|
|
|
|
|
| |
Remove yet another spurious unexpected success.
Ack'ed by Jim Ingham.
Fixes PR25743.
llvm-svn: 320454
|
|
|
|
|
|
|
|
|
| |
I tested on x86-64 and Jason on embedded architectures.
This cleans up another couple of reported unexpected successes.
<rdar://problem/28623427>
llvm-svn: 320452
|
|
|
|
|
|
|
| |
With this one, the number of unexpected successes for the LLDB
test suite when building with clang ToT goes down to 18.
llvm-svn: 320450
|
|
|
|
|
|
|
|
| |
After discussing this with Jim and Jason, I think my commit was
actually sweeping the issue under the carpet rather than fixing it.
I'll take a closer look between tonight and tomorrow.
llvm-svn: 320447
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some tests are failing on macOS when building with the in-tree
clang, and this is because they're conditional on the version released.
Apple releases using a different versioning number, but as these are
conditional on clang < 7, they fail for clang ToT (which is 6.0).
As a general solution, we actually need either a mapping between
Apple internal release version and public ones.
That said, I discussed this with Fred , and Apple Clang 6.0 seems
to be old enough that we can remove this altogether (which means I
can delay implementing the general purpose solution for a bit).
Differential Revision: https://reviews.llvm.org/D41101
llvm-svn: 320444
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the install-*-stripped targets to LLDB, which are required for
the install-distribution-stripped option. We also need to create some
install-*-stripped targets manually, which are modeled after their
corresponding install-* targets.
Differential Revision: https://reviews.llvm.org/D41099
llvm-svn: 320443
|
|
|
|
|
|
|
|
|
|
| |
This is the first of a series of commits aiming to improve
overall LLDB's hygiene. Feel free to shout at me in case
I break something.
<rdar://problem/30915340>
llvm-svn: 320425
|
|
|
|
|
|
|
|
| |
Should hopefully bring the bots back.
<rdar://problem/35976115>
llvm-svn: 320422
|
|
|
|
|
|
|
| |
This enables one to run all dwo tests with dotest.py --category dwo, or
skip them with --skip-category.
llvm-svn: 320377
|
|
|
|
|
|
|
|
|
| |
Host::GetEnvironment returns a StringList, but the interface for
launching a process takes Args. The fact that we use two classes for
representing an environment is not ideal, but for now we should at least
have an easy way to convert between the two.
llvm-svn: 320366
|
|
|
|
| |
llvm-svn: 320349
|
|
|
|
|
|
|
| |
lldb_utility doesn't make sense, as it is no longer even living in the
"utility" module.
llvm-svn: 320346
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
For ptys (at least on Linux), the end-of-file (closing of the slave FD)
is signalled by the POLLHUP flag. We were ignoring this flag, which
meant that when this happened, we would spin in a loop, continuously
calling poll(2) and not making any progress.
This makes sure we treat POLLHUP as a read event (reading will return
0), and we call the registered callback when it happens. This is the
behavior our clients expect (and is consistent with how select(2)
works).
Reviewers: eugene, beanz
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D41008
llvm-svn: 320345
|
|
|
|
|
|
|
| |
The commit exposes a bunch of failures in the LLDB testsuite that
I need to analyze more carefully. Reverting for now.
llvm-svn: 320341
|
|
|
|
| |
llvm-svn: 320338
|
|
|
|
| |
llvm-svn: 320337
|
|
|
|
|
|
|
|
|
|
| |
They cause an ubsan error when ran through the testsuite (store
to misaligned address is UB). This commit kills two birds with
one stone, as we also remove some code while fixing it.
<rdar://problem/35941757>
llvm-svn: 320335
|
|
|
|
|
|
|
|
| |
for better safety.
<rdar://problem/32906923>
llvm-svn: 320242
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
computer. When doing kernel debugging, lldb scrapes around a few
well-known locations to find kexts and kernels. It builds up two
lists - kexts and kernels with dSYM, and kexts and kernels without dSYMs.
After both lists have failed to provide a file, then we'll call out
to things like the DebugSymbols framework to find a kext/kernel.
This meant that when you had a kext/kernel on the local computer that
did not have debug information, lldb wouldn't consult DebugSymbols etc
once it'd locked on to one of these no-debug-info binaries on the local
computer.
Reorder this so we give DebugSymbols etc a shot at finding a debug-info
file before we use any of the no-debug-info binaries that were found on
the system.
<rdar://problem/34434440>
llvm-svn: 320241
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
most common cases where the Xcode.app bundle puts lldb -
either as a default part of the bundle, or in a toolchain
subdirectory, so the platform subclasses can find files
relative to this directory.
Dropped support for handling the case where the lldb
framework was in /Library/PrivateFrameworks. I think
this was intended to handle the case where lldb is installed
in / (outside the Xcode.app bundle) - but in that case, we
can look in the raw directory file paths to find anything.
<rdar://problem/35285622>
llvm-svn: 320240
|
|
|
|
|
|
|
|
|
|
|
| |
Fix alignment UB in some Mach exception-handling logic.
This lets us build lldb and debugserver with UBSan in trapping mode, and
get further along in the testing process before a trap is encountered.
rdar://35923991
llvm-svn: 320127
|
|
|
|
|
|
| |
Thanks to Jim Ingham for providing the explanation!
llvm-svn: 320126
|
|
|
|
|
|
| |
Mark them as such.
llvm-svn: 320077
|
|
|
|
|
|
|
|
|
|
|
| |
This part of lldb make use of anonymous structs and unions. The usage is
idiomatic and doesn't deserve a warning. Logic in the NSDictionary and NSSet
plugins use anonymous structs in a manner consistent with the relevant Apple
frameworks.
Differential Revision: https://reviews.llvm.org/D40757
llvm-svn: 320071
|
|
|
|
| |
llvm-svn: 320067
|
|
|
|
|
|
|
|
|
|
| |
They're hidden, so all they cause is a linker warning.
ld: warning: cannot export hidden symbol
lldb::SBBreakpointNameImpl::operator==(lldb::SBBreakpointNameImpl const&) from
tools/lldb/source/API/CMakeFiles/liblldb.dir/SBBreakpointName.cpp.o
llvm-svn: 320066
|
|
|
|
| |
llvm-svn: 320060
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Variable::GetValuesForVariableExpressionPath was passing an
uninitialised value for the final_task_on_target argument. On my
compiler/optimization level combo, the final_task_on_target happened to
contain "dereference" in some circumstances, which produced hilarious
results. The same is true for other arguments to the
GetValueForExpressionPath call.
The correct behavior here seems to be to just omit the arguments
altogether and let the default behavior take place.
Reviewers: jingham
Subscribers: mehdi_amini, lldb-commits
Differential Revision: https://reviews.llvm.org/D40557
llvm-svn: 320021
|
|
|
|
|
|
|
|
| |
This is a follow-up to r319840. I guess none of the systems I'd tested
on before had LLDB_SYSTEM_LIBS set, which is why I didn't see any local
errors, but I'm surprised none of the bots caught it either.
llvm-svn: 319953
|
|
|
|
|
|
|
| |
r319938 was not NFC, because it got the preprocessor guard wrong. Check
WITH_FBS and WITH_BKS before defining SplitEventData.
llvm-svn: 319943
|