The recent UUID cleanups exposed a bug in the parsing code for the
jModulesInfo response, which was passing wrong value for the second
argument to UUID::SetFromStringRef (it passed the length of the string,
whereas the correct value should be the number of decoded bytes we
expect to receive).
This was not picked up by tests, because they test with 16-byte uuids,
for which the function happens to do the right thing even if the length
does not match (if the length does not match, the function does not
update m_num_uuid_bytes member, but that member is already 16 to begin
with).
I fix that and add a test with 20-byte uuid to catch if this regresses.
I have also added more safeguards into the parsing code to fail if we
cannot parse the entire uuid field we recieve. While testing the latter
part, I noticed that the "negative" jModulesInfo tests were succeeding
because we were sending malformed json (and not because the json
contents was invalid), so I make those tests a bit more robuts as well.
llvm-svn: 320985
Summary:
We were failing to propagate the environment when lldb-server was
started with a pre-loaded process
(e.g.: lldb-server gdbserver -- inferior --inferior_args)
This patch makes sure the environment is propagated. Instead of adding a
new GDBRemoteCommunicationServerLLGS::SetLaunchEnvironment function to
complement SetLaunchArgs and SetLaunchFlags, I replace these with a
more generic SetLaunchInfo, which can be used to set any launch-related
property.
The accompanying test also verifies that the server correctly terminates
the connection after sending the exit packet (specifically, that it does
not send the exit packet twice).
Reviewers: clayborg, eugene
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D41070
llvm-svn: 320984
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
"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
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
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
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
This is needed to ensure that the distribution and install-distribution
targets work properly.
Differential Revision: https://reviews.llvm.org/D41144
llvm-svn: 320537
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
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
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
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
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
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
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
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
Pavel Labath