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
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
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
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
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
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
A few methods in RegisterContext classes accept const objects which are
cast to a non-const thread_state_t. Drop const-ness more explicitly
where we mean to do so. This fixes a slew of warnings.
Differential Revision: https://reviews.llvm.org/D40821
llvm-svn: 319939
Null-checking functions which aren't marked weak_import is a no-op
(the compiler rewrites the check to 'true'), regardless of whether a
library providing its definition is weak-linked. If the deployment
target is greater than the minimum requirement, the availability markup
on APIs does not lower to weak_import.
Remove no-op null checks to clean up the code and silence warnings.
Differential Revision: https://reviews.llvm.org/D40812
llvm-svn: 319936
Summary: There are "FIXME"s in include/llvm/IR/DataLayout.h to remove the default arguments.
Reviewers: zturner, clayborg
Reviewed By: zturner
Subscribers: bjope
Differential Revision: https://reviews.llvm.org/D40064
llvm-svn: 319869
Also add a test. There should also be control for this
in ProcessLaunchInfo and a "target launch" flag, but at least
this will allow you to control it somehow.
<rdar://problem/35842137>
llvm-svn: 319731
I was warning about the fact that this will abort
further stop hooks, but didn't check that there WAS
a further stop hook. Also the warning was missing a
newline.
llvm-svn: 319730
LLDB.framework gets loaded into Xcode and other
frameworks, and this is inserting a signal handler into
the process even when lldb isn't used. I have a bunch
of reports of this SignalHandler blowing out the stack,
which renders crash reports for the crash useless.
And in any case libraries really shouldn't be installing
signal handlers.
I only turned this off for APPLE platforms, I'll let
the maintainers of other platforms decide what policy
they want to have w.r.t. this.
llvm-svn: 319598
struct iovec is used as an interface to system (posix) api's. As such,
we shouldn't be using it in os-independent code, and we shouldn't be
defining our own iovec replacements.
Fortunately, its usage was not very widespread, so the removal was very
easy -- I simply moved a couple declarations into os-specific code.
llvm-svn: 319536
but still listed in the kernel's kext table with the kernel
binary UUID. This resulted in the kernel text section being
loaded at the kext address and problems ensuing. Instead,
if there is a kext with the same UUID as the kernel, lldb
should skip over it.
<rdar://problem/35757689>
llvm-svn: 319500
1. Move TaskPool into the namespace lldb_private.
2. Add missing std::move in TaskPoolImpl::Worker.
3. std:🧵:hardware_concurrency may return 0,
handle this case correctly.
Differential revision: https://reviews.llvm.org/D40587
Test plan: make check-all
llvm-svn: 319492
Adrian Prantl