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:
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
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 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
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
This is basically a proof-of-concept and starting point for having a
testing-centric tool in LLDB. I'm sure this leaves a lot of room to be
desired, but this at least allows us to have something to build on.
Right now there is only one command, the `module-sections` command, and I
created this command not because it was particularly special, but
because it addressed an immediate use case and was extremely simple.
Run the tool as `lldb-test module-sections <path-to-object>`.
Feel free to add testing related stuff to your heart's content after
this goes in. Implementing the commands themselves takes some work, but
once they're there they can be reused without writing any code and
result in very easy to use and maintain tests.
Differential Revision: https://reviews.llvm.org/D40636
llvm-svn: 319504
Summary:
r316368 broke this build when it introduced a reference to a pthread
function to the Utility module. This caused cmake to generate an
incorrect link line (wrong order of libs) because it did not see the
dependency from Utility to the system libraries. Instead these libraries
were being manually added to each final target.
This changes moves the dependency management from the individual targets
to the lldbUtility module, which is consistent with how llvm does it.
The final targets will pick up these libraries as they will be a part of
the link interface of the module.
Technically, some of these dependencies could go into the host module,
as that's where most of the os-specific code is, but I did not try to
investigate which ones.
Reviewers: zturner, sylvestre.ledru
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D39246
llvm-svn: 316997
Using TCP sockets is insecure against local attackers, and possibly
against remote attackers too (some vulnerabilities may allow tricking a
browser to make a request to localhost). Use socketpair (which is immune
to such attacks) on all Unix platforms.
Patch by Demi Marie Obenour < demiobenour@gmail.com >
Differential Revision: https://reviews.llvm.org/D33213
llvm-svn: 314127
1. Fix a data race (g_interrupt_sent flag usage was not thread safe, signals
can be handled on arbitrary threads)
2. exit() is not signal-safe, replaced it with the signal-safe equivalent
_exit()
(This differs from the patch on Phabrictor because I had to add
`#include <atomic>` to get the definition of `std::atomic_flag`.)
patch by lemo
Differential Revision: https://reviews.llvm.org/D37926
llvm-svn: 313785
Turns out WITH_LOCKDOWN define changes the struct layout and constructor implementation for RNBSocket which is used in debugserver.cpp, so we need to make sure this is consistent.
In the future we should change WITH_LOCKDOWN to be configured in a generated header, but for now we can just set it correctly.
<rdar://problem/33900552>
llvm-svn: 312666
Summary:
-var-update calls CMICmdCmdVarUpdate::ExamineSBValueForChange to check if a varObj has been updated. It checks that the varObj is updated, then recurses on all of its children. If a child is a pointer pointing back to a parent node, this will result in an infinite loop, and lldb-mi hanging.
The problem is exposed by packages/Python/lldbsuite/test/tools/lldb-mi/variable/TestMiVar.py, but this test is skipped everywhere.
This patch changes ExamineSBValueForChange to not traverse children of varObjs that are pointers.
Reviewers: ki.stfu, zturner, clayborg, abidh
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D37154
llvm-svn: 312270
to match the changes Saleem Abdulrasool committed in r311579. Fixes
a testsuite failure now that the testsuite expects a 16 bit return
value for thsi reg.
llvm-svn: 311627
-- 2 files were missing in this commit which should have been there.
These files were submitted initially for review and were reviewed.
However, while updating the revision with newer diffs, I accidentally
forgot to include them in newer diffs. So commiting now.
llvm-svn: 310341
Summary:
1. Provide single library for all Intel specific hardware features instead
of individual libraries for each feature
2. Added Intel(R) Processor Trace hardware feature in this single library.
Details about the tool implementing this feature is as follows:
Tool developed on top of LLDB to provide its users the execution
trace of the debugged inferiors. Tool's API are exposed as C++ object
oriented interface in a shared library. API are designed especially to be
easily integrable with IDEs providing LLDB as an application debugger.
Entire API is also available as Python functions through a script bridging
interface allowing development of python modules.
This patch also provides a CLI wrapper to use the Tool through LLDB's command
line. Highlights of the Tool and the wrapper are given below:
******************************
Intel(R) Processor Trace Tool:
******************************
- Provides execution trace of the debugged application
- Uses Intel(R) Processor Trace hardware feature (already implemented inside LLDB)
for this purpose
-- Collects trace packets generated by this feature from LLDB, decodes and
post-processes them
-- Constructs the execution trace of the application
-- Presents execution trace as a list of assembly instructions
- Provides 4 APIs (exposed as C++ object oriented interface)
-- start trace with configuration options for a thread/process,
-- stop trace for a thread/process,
-- get the execution flow (assembly instructions) for a thread,
-- get trace specific information for a thread
- Easily integrable into IDEs providing LLDB as application debugger
- Entire API available as Python functions through script bridging interface
-- Allows developing python apps on top of Tool
- README_TOOL.txt provides more details about the Tool, its dependencies, building
steps and API usage
- Tool ready to use through LLDB's command line
-- CLI wrapper has been developed on top of the Tool for this purpose
*********************************
CLI wrapper: cli-wrapper-pt.cpp
*********************************
- Provides 4 commands (syntax similar to LLDB's CLI commands):
-- processor-trace start
-- processor-trace stop
-- processor-trace show-trace-options
-- processor-trace show-instr-log
- README_CLI.txt provides more details about commands and their options
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: clayborg, jingham, lldb-commits, labath
Reviewed By: clayborg
Subscribers: ravitheja, emaste, krytarowski, mgorny
Differential Revision: https://reviews.llvm.org/D33035
llvm-svn: 310261
When building for iOS we build two variants of debugserver. One which supports UI functionality like Springboard for launching applications, and one which does not.
This patch adds support for building debugserver with and without UI support libraries being available.
llvm-svn: 309026
This refactoring changes two significant things about how the debugserver build system works:
(1) debugserver will include all appropriate architecture support, so we can now build arm or ppc debugservers
(2) debugserver can be built by itself, so you don't have to configure all of LLDB in order to generate debugserver.
llvm-svn: 308377
Summary:
It defined a couple of types (condition_t) which we don't use anymore,
as we have c++11 goodies now. I remove these definitions.
Also it unnecessarily included a couple of headers which weren't
necessary for it's operation. I remove these, and place the includes in
the relevant files (usually .cpp, usually in Host code) which use them.
This allows us to reduce namespace pollution in most of the lldb files
which don't need the OS-specific definitions.
Reviewers: zturner, jingham
Subscribers: ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D35113
llvm-svn: 308304
Summary:
The usage of shared_from_this forces us to separate construction and
initialization phases, because shared_from_this() is not available in
the constructor (or destructor). The shared semantics are not necessary,
as we always have a clear owner of the native process class
(GDBRemoteCommunicationServerLLDB object). Even if we need shared
semantics in the future (which I think we should strongly avoid),
reverting this will not be necessary -- the owners can still easily
store the native process object in a shared pointer if they really want
to -- this just prevents the knowledge of that from leaking into the
class implementation.
After this a NativeThread object will hold a reference to the parent
process (instead of a weak_ptr) -- having a process instance always
available allows us to simplify some logic in this class (some of it was
already simplified because we were asserting that the process is
available, but this makes it obvious).
Reviewers: krytarowski, eugene, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D35123
llvm-svn: 308282
While adding IPv6 support to debugserver I broke handling wildcard addresses and fully qualified address filtering. This patch resolves that bug and adds a test for matching the address "*".
<rdar://problem/32947613>
llvm-svn: 307957
Summary:
This replaces the static functions used for creating
NativeProcessProtocol instances with a factory pattern, and modernizes
the interface of the new class in the process -- I use llvm::Expected
instead of the Status+value combo. I also move some of the common code
(like the Delegate registration into the base class). The new
arrangement has multiple benefits:
- it removes the NativeProcess*** dependency from Process/gdb-remote
(which for example means that liblldb no longer pulls in this code).
- it enables unit testing of the GDBRemoteCommunicationServerLLGS class
(by providing a mock Native Process).
- serves as another example on how to use the llvm::Expected class (I
couldn't get rid of the Initialize-type functions completely here
because of the use of shared_from_this, but that's the next thing on
my list here)
Tests still pass on Linux and I've made sure NetBSD compiles after this.
Reviewers: zturner, eugene, krytarowski
Subscribers: srhines, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33778
llvm-svn: 307390
Summary:
These interfaces have no dependencies, so it makes sense for them to be
in the lowest level modules, to make sure that other parts of the
codebase can use them without introducing loops.
The only exception here is the Connection::CreateDefaultConnection
method, which I've moved to Host, as it instantiates concrete
implementations, and that's where the implementations live.
Reviewers: jingham, zturner
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D34400
llvm-svn: 306391
strerror is not thread-safe. llvm's StrError tries hard to retrieve the
string in a thread-safe way and falls back to strerror only if it does
not have another way.
llvm-svn: 304795