Summary:
Add basic OpenBSD support. This is enough to be able to analyze core dumps for OpenBSD/amd64, OpenBSD/arm, OpenBSD/arm64 and OpenBSD/i386.
Note that part of the changes to source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp fix a bug that probably affects other platforms as well. The GetProgramHeaderByIndex() interface use 1-based indices, but in some case when looping over the headers the, the loop starts at 0 and misses the last header. This caused problems on OpenBSD since OpenBSD core dumps have the PT_NOTE segment as the last program header.
Reviewers: joerg, labath, krytarowski
Reviewed By: krytarowski
Subscribers: aemerson, emaste, rengolin, srhines, krytarowski, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31131
llvm-svn: 298810
There are only two users of NativeRegisterContextRegisterInfo,
and both are in process plugins. Moving this code from Host
to Plugins/Process/Utility thus makes sense, and as it is the
only dependency from Host -> PluginProcessUtility, it also
breaks this cycle, reducing LLDB's overall cycle count from
45 to 44.
llvm-svn: 298466
Summary:
These two register contexts were identical, so this shouldn't cause any
regressions, but I'd appreciate it if you can check that this at least compiles.
Reviewers: emaste, sas
Subscribers: aemerson, rengolin, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27126
llvm-svn: 296335
Summary:
This is a test-the-water change about possibilities of reducing duplication in
the register context definitions.
I've named the new class RegisterInfoPOSIX, as RegisterContextPOSIX was already
taken :(. The two files were identical except for a fix by Tamas in D12636,
which was applied to the Linux version only, which fixed a discrepancy between
the definitions of fpsr and fpcr on one hand, and all other floating point
register definitions on the other.
Linux test suite still passes after this change. For freebsd, make the floating
point register behavior consistent, but I don't know whether it will be
consistently fixed, or consistently broken. By eyeballing the code, I have a
feeling that a similar fix to D12636 will be required in
RegisterContextPOSIXProcessMonitor_arm64::ReadRegister, but I can't be sure as I
have no way to test it (the assert in that function should fire upon accessing
the registers if it is wrong though).
Reviewers: emaste, clayborg
Subscribers: aemerson, rengolin, beanz, mgorny, modocache, dmikulin, lldb-commits
Differential Revision: https://reviews.llvm.org/D25947
llvm-svn: 287916
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
Summary:
This doesn't exist in other LLVM projects any longer and doesn't
do anything.
Reviewers: chaoren, labath
Subscribers: emaste, tberghammer, lldb-commits, danalbert
Differential Revision: http://reviews.llvm.org/D12586
llvm-svn: 246749
Summary:
- Consolidate Unix signals selection in UnixSignals.
- Make Unix signals available from platform.
- Add jSignalsInfo packet to retrieve Unix signals from remote platform.
- Get a copy of the platform signal for each remote process.
- Update SB API for signals.
- Update signal utility in test suite.
Reviewers: ovyalov, clayborg
Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D11094
llvm-svn: 242101
This patch is major step towards supporting lldb on ARM.
This adds all the required bits to support register manipulation on Linux Arm.
Also adds utility enumerations, definitions and register context classes for arm.
llvm-svn: 234870
Summary:
This adds preliminary support for PowerPC/PowerPC64, for FreeBSD. There are
some issues still:
* Breakpoints don't work well on powerpc64.
* Shared libraries don't yet get loaded for a 32-bit process on powerpc64 host.
* Backtraces don't work. This is due to PowerPC ABI using a backchain pointer
in memory, instead of a dedicated frame pointer register for the backchain.
* Breakpoints on functions without debug info may not work correctly for 32-bit
powerpc.
Reviewers: emaste, tfiala, jingham, clayborg
Reviewed By: clayborg
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D5988
llvm-svn: 220944
Yet another step toward ARM64 support. With this commit, lldb-gdbserver started on ARM64 target can be accessed by lldb running on desktop PC and it can process simple commands (like 'continue'). Still ARM64 support lacks NativeRegisterContextLinux_arm64.* code which waits to be implemented.
Based on similar files for Linux x86_64 and Darwin ARM64. Due to common code extraction from Darwin related files, lldb should be tested for any unexpected regression on Darwin ARM64 machines too.
See the following for more details:
http://reviews.llvm.org/D4580http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140825/012670.html
Change by Paul Osmialowski.
llvm-svn: 216737
Also moves NativeRegisterContextLinux* files into the Linux directory.
These, like NativeProcessLinux, should only be built on Linux or a cross
compiler with proper headers.
llvm-svn: 212074
This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64.
(More architectures coming soon).
Not every debugserver option is covered yet. Currently
the lldb-gdbserver command line can start unattached,
start attached to a pid (process-name attach not supported yet),
or accept lldb attaching and launching a process or connecting
by process id.
The history of this large change can be found here:
https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64
Until mid/late April, I was not sharing the work and continued
to rebase it off of head (developed via id tfiala@google.com). I switched over to
user todd.fiala@gmail.com in the middle, and once I went to github, I did
merges rather than rebasing so I could share with others.
llvm-svn: 212069
These changes were written by Greg Clayton, Jim Ingham, Jason Molenda.
It builds cleanly against TOT llvm with xcodebuild. I updated the
cmake files by visual inspection but did not try a build. I haven't
built these sources on any non-Mac platforms - I don't think this
patch adds any code that requires darwin, but please let me know if
I missed something.
In debugserver, MachProcess.cpp and MachTask.cpp were renamed to
MachProcess.mm and MachTask.mm as they picked up some new Objective-C
code needed to launch processes when running on iOS.
llvm-svn: 205113
Fix Windows build by adding JITLoaderGDB and ProcessElfCore.
RegisterContext: fixes for Windows build: sizeof(GPR::register) didn't work, switched to sizeof(((GPR*)NULL)->register).
llvm-svn: 203667
Still working out some of the details of these classes but
I wanted to get the overall structure checked in.
<rdar://problem/15314068>
llvm-svn: 194245
- generate-vers.pl has to be called by cmake to generate the version number
- parallel builds not yet supported; dependency on clang must be explicitly specified
Tested on Linux.
- Building on Mac will require code-signing logic to be implemented.
- Building on Windows will require OS-detection logic and some selective directory inclusion
Thanks to Carlo Kok (who originally prepared these CMakefiles for Windows) and Ben Langmuir
who ported them to Linux!
llvm-svn: 175795