Patch by Nitesh Jain.
Summary : The problem appears while linking liblldb.so. The class Address contain atomic variable m_offset. The loading and storing of variable is access via atomic_load_8 and atomic_store_8 functions. Some target fail to implicitly link libatomic, which cause undefine reference to atomic_store_8/atomic_load_8. This patch uses http://reviews.llvm.org/D20896 to check if libatomic need to be explicitly link.
Reviewed by labath.
Differential: D20464
llvm-svn: 274121
This patch adds support for Linux on SystemZ:
- A new ArchSpec value of eCore_s390x_generic
- A new directory Plugins/ABI/SysV-s390x providing an ABI implementation
- Register context support
- Native Linux support including watchpoint support
- ELF core file support
- Misc. support throughout the code base (e.g. breakpoint opcodes)
- Test case updates to support the platform
This should provide complete support for debugging the SystemZ platform.
Not yet supported are optional features like transaction support (zEC12)
or SIMD vector support (z13).
There is no instruction emulation, since our ABI requires that all code
provide correct DWARF CFI at all PC locations in .eh_frame to support
unwinding (i.e. -fasynchronous-unwind-tables is on by default).
The implementation follows existing platforms in a mostly straightforward
manner. A couple of things that are different:
- We do not use PTRACE_PEEKUSER / PTRACE_POKEUSER to access single registers,
since some registers (access register) reside at offsets in the user area
that are multiples of 4, but the PTRACE_PEEKUSER interface only allows
accessing aligned 8-byte blocks in the user area. Instead, we use a s390
specific ptrace interface PTRACE_PEEKUSR_AREA / PTRACE_POKEUSR_AREA that
allows accessing a whole block of the user area in one go, so in effect
allowing to treat parts of the user area as register sets.
- SystemZ hardware does not provide any means to implement read watchpoints,
only write watchpoints. In fact, we can only support a *single* write
watchpoint (but this can span a range of arbitrary size). In LLDB this
means we support only a single watchpoint. I've set all test cases that
require read watchpoints (or multiple watchpoints) to expected failure
on the platform. [ Note that there were two test cases that install
a read/write watchpoint even though they nowhere rely on the "read"
property. I've changed those to simply use plain write watchpoints. ]
Differential Revision: http://reviews.llvm.org/D18978
llvm-svn: 266308
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
The purpose of these plugins is to make LLDB capable of debugging java
code JIT-ed by the android runtime.
Differential revision: http://reviews.llvm.org/D17616
llvm-svn: 262015
Summary:
This approach is tunable with custom paths for curses library.
It also detects whether there are requirements met.
I make use of it on NetBSD.
Patch by Kamil Rytarowski. Thanks!
Reviewers: clayborg
Subscribers: brucem, joerg, lldb-commits
Differential Revision: http://reviews.llvm.org/D14529
llvm-svn: 253151
Summary:
These changes are still incomplete, but we are almost there.
Changes:
- CMake and gmake code
- SWIG code
- minor code additions
Reviewers: emaste, joerg
Subscribers: youri, akat1, brucem, lldb-commits, joerg
Differential Revision: http://reviews.llvm.org/D14042
llvm-svn: 252403
The Go interpreter doesn't JIT or use LLVM, so this also
moves all the JIT related code from UserExpression to a new class LLVMUserExpression.
Differential Revision: http://reviews.llvm.org/D13073
Fix merge
llvm-svn: 251820
Summary:
I see a lot of following warnings in LLDBWrapPython.cpp while building with gcc 4.9 on Linux.
"warning: cast from type ‘const char*’ to type ‘char*’ casts away qualifiers [-Wcast-qual]"
Is it ok to add -Wno-cast-qual for this file in cmake for gcc. This option seems to be already present
for autotool case.
Reviewers: zturner, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13719
llvm-svn: 250380
Summary:
This is Darwin only.
The symbol defined by ${LLDB_VERS_GENERATED_FILE} is used by
source/lldb.cpp, so anything that uses lldb.cpp (which is in
lldbBase) should also have the generated symbol. This means
that the entire process can be centralized within source/CMakeLists.txt
where lldbBase is constructed.
Additionally, the custom command should have dependencies on the
project file as well as the generation script so that if either
changes, the version file is correctly re-generated and everything
is re-linked appropriately.
* cmake/LLDBDependencies.cmake: Remove everything related to
the generated version file from here.
* source/CMakeLists.txt: On Darwin, add the generated version
file to the sources that make up lldbBase. Also, create a
custom target and make lldbBase depend on it to re-generate
the generated file as needed.
* source/API/CMakeLists.txt: Don't need to build the generated
version file here or use it to control linking against swig_wrapper.
* tools/lldb-server/CMakeLists.txt: Likewise.
Reviewers: dawn, sas, clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13552
llvm-svn: 249806
Summary: We were missing the symbol for the version number.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13271
llvm-svn: 249434
The Go runtime schedules user level threads (goroutines) across real threads.
This adds an OS plugin to create memory threads for goroutines.
It supports the 1.4 and 1.5 go runtime.
Differential Revision: http://reviews.llvm.org/D5871
llvm-svn: 247852
Ncurses related symbols can either all be found in libnurses or split
between libncurses and libtinfo. The main LLVM cmake scripts look for the
setupterm symbol and stores the library that has it in TERMINFO_LIBS. This
covers the split and unified ncurses case. LLDB uses symbols that can end
up in libtinfo so this library should be pulled in if it is found.
There is still an exotic case left where LLDB is configured with
-DLLDB_DISABLE_CURSES=NO and LLVM with -DLLVM_ENABLE_TERMINFO=NO but
misconfigurations will always be possible. Possibly a diagnostic could be
added for that.
This fixes bug 24693.
Differential Revision: http://reviews.llvm.org/D12672
Patch by Jeremi Piotrowski
llvm-svn: 247842
Summary:
* cmake/LLDBDependencies.cmake: elf-core is already included
globally in LLDB_USED_LIBS, so it doesn't need to be re-added
on individual platforms.
* lib/Makefile: elf-core is linked on each platform, so move it
to the global list of used libraries.
* source/Plugins/Makefile: elf-core is built on each platform, so
move it to the global list of things to build.
Reviewers: clayborg, labath
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12762
llvm-svn: 247366
Summary:
We currently link to this on all platforms, so don't need to re-include
it into the LLDB_USED_LIBS. Also don't need to special case building
it for every supported platform.
Reviewers: clayborg, labath
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12756
llvm-svn: 247284
Historically, data formatters all exist in a global repository (the category map)
On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex)
This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on
The advantages of this are:
a) language formatters only get created when they might apply
b) formatters for a language are clearly owned by the matching language plugin
The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager
In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters
No formatters are moved as part of this change, so practically speaking this is NFC
llvm-svn: 246568
With static linking lldb-server crashes in platform mode when
tries to listen on localhost:5432 on the android build bot.
This reverts commit 3ea861707dec8423746679ff496e4fd03255d4cf.
llvm-svn: 242401
Summary:
This commit moves the Windows DyanamicLoader to the common DynamicLoader
directory. This is required to remote debug Windows targets.
This commit also initializes the Windows DYLD plugin in
SystemInitializerCommon (similarly to both POSIX and MacOSX DYLD
plugins) so that we can automatically instantiate this class when
connected to a windows process.
Test Plan: Build.
Reviewers: zturner
Subscribers: lldb-commits, abdulras
Differential Revision: http://reviews.llvm.org/D10882
llvm-svn: 241697
Summary:
Several changes to fix CMake builds of LLDB with the
BUILD_SHARED_LIBS setting on.
- Force all internal libraries to be built STATIC.
- Add additional library dependencies (pthread, dl,
runtimedyld).
- modify finalisation of SWIG wrapper to symlink the
"lib" dir into python/site-packages, so _lldb.so's
RPATH resolves.
Test Plan: Verified one test case with "dotest.py".
Reviewers: sylvestre.ledru, zturner
Reviewed By: zturner
Subscribers: zturner, ted, tberghammer, emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D10157
llvm-svn: 239007
Summary:
Implementation of assembly profiler for MIPS32 using EmulateInstruction which currently scans only prologue/epilogue assembly instructions. It uses llvm::MCDisassembler to decode assembly instructions.
Reviewers: clayborg, jasonmolenda
Differential Revision: http://reviews.llvm.org/D9769
llvm-svn: 237420
This code is also an import from MacOSx implementation as SysV abi is
similar to what has been implemented for MacOS but may require a few tweaks.
http://reviews.llvm.org/D8538
llvm-svn: 236098
Its mostly imported from MacOSx ABI for arm which is similar.
Further tweaking a updates may be required at a later stage.
http://reviews.llvm.org/D8539
llvm-svn: 236097
Plan is to have this initialized on a per-process basis somewhat the same as the ObjC library on module loading, but this commit is simply the foundation work and will be incrementally built upon to add that detection functionality.
Differential Revision: http://reviews.llvm.org/D8896
llvm-svn: 234503
There were a couple of real bugs here regarding error checking and
signed/unsigned comparisons, but mostly these were just noise.
There was one class of bugs fixed here which is particularly
annoying, dealing with MSVC's non-standard behavior regarding
the underlying type of enums. See the comment in
lldb-enumerations.h for details. In short, from now on please use
FLAGS_ENUM and FLAGS_ANONYMOUS_ENUM when defining enums which
contain values larger than can fit into a signed integer.
llvm-svn: 233943
This creates a new top-level folder called Initialization which
is intended to hold code specific to LLDB system initialization.
Currently this holds the Initialize() and Terminate() functions,
as well as the fatal error handler.
This provides a means to break the massive dependency cycle which
is caused by the fact that Debugger depends on Initialize and
Terminate which then depends on the entire LLDB project. With
this structure, it will be possible for applications to invoke
lldb_private::Initialize() directly, and have that invoke
Debugger::Initialize.
llvm-svn: 232768
Summary:
This is initial implementation of assembly profiler which only scans prologue/epilogue assembly instructions to create CFI instructions.
Reviewers: clayborg, jasonmolenda
Differential Revision: http://reviews.llvm.org/D7696
llvm-svn: 232619
Separate out the necessary component initialization for lldb-server such that the linker can greatly reduce the binary size. With this patch the size of lldb-server on my 64 bit linux release build drops from 46MB to 26MB.
Differential Revision: http://reviews.llvm.org/D7880
llvm-svn: 230963
This resubmits r230380. The primary cause of the failure was
actually just a warning, which we can disable at the CMake level
in a followup patch on the LLVM side. The other thing which was
actually an error on the bot should be able to be fixed with
a clean.
llvm-svn: 230389
An OBJECT library is a special type of CMake library that produces
no archive, has no link interface, and no link inputs. It is like
a regular archive, just without the physical output. To link
against an OBJECT library, you reference it in the *source* file
list of a library using the special syntax $<TARGET_OBJECTS:lldbAPI>.
This will cause every object file to be passed to the linker
independently, as opposed to a single archive being passed to the
linker.
This is *extremely* important on Windows. lldbAPI exports all of the
SB classes using __declspec(dllexport). Unfortunately for technical
reasons it is not possible (well, extremely difficult) to get the
linker to propagate a __declspec(dllexport) attribute from a symbol
in an object file in an archive to a DLL that links against that
archive. The solution to this is for the DLL to link the object files
directly. So lldbAPI must be an OBJECT library.
This fixes an issue that has been present since the duplicated
lldbAPI file lists were removed, which would cause linker failures.
As a side effect, this also makes LLDB_DISABLE_PYTHON=1 work again
on Windows, which was previously totally broken.
llvm-svn: 230380
* Create new platform plugin for lldb
* Create HostInfo class for android
* Create ProcessLauncher for android
Differential Revision: http://reviews.llvm.org/D7584
llvm-svn: 228943
BUILD_SHARED_LIBS=TRUE currently isn't working for Linux x86_64
This patch fixes the link errors and also some runtime errors
Test Plan:
CC=clang CXX=clang++ cmake -GNinja -DBUILD_SHARED_LIBS=TRUE -DCMAKE_LINKER=ld.gold -DCMAKE_BUILD_TYPE=Debug ../../llvm
ninja
ninja check-lldb
llvm-svn: 226039
Sagar Thakur