summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process
Commit message (Collapse)AuthorAgeFilesLines
* Revert "[lldb] Use vFlash commands when writing to target's flash memory ↵Pavel Labath2018-02-284-335/+9
| | | | | | | | | | | | regions" This reverts commit r326261 as it introduces inconsistencies in the handling of load addresses for ObjectFileELF -- some parts of the class use physical addresses, and some use virtual. This has manifested itself as us not being able to set the load address of the vdso "module" on android. llvm-svn: 326367
* [lldb] Use vFlash commands when writing to target's flash memory regionsPavel Labath2018-02-274-9/+335
| | | | | | | | | | | | | | | | | | | | | | Summary: When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup. - Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address. - Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications - Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html Reviewers: clayborg, labath Reviewed By: labath Subscribers: arichardson, emaste, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D42145 Patch by Owen Shaw <llvm@owenpshaw.net> llvm-svn: 326261
* [Utility] Simplify and generalize the CleanUp helper, NFCVedant Kumar2018-02-231-18/+13
| | | | | | | | | | | | | | | | | | Removing the template arguments and most of the mutating methods from CleanUp makes it easier to understand and reuse. In its present state, CleanUp would be too cumbersome to adapt to cases where multiple objects need to be released. Take for example this change in swift-lldb: https://github.com/apple/swift-lldb/pull/334/files#diff-6f474df750f75c8ba675f2a8408a5629R219 This change is simple to express with the new CleanUp, but not so simple with the old version. Differential Revision: https://reviews.llvm.org/D43662 llvm-svn: 325964
* [LLDB][PPC64] Fixed next blocked forever at same linePavel Labath2018-02-211-5/+1
| | | | | | | | | | | | | | | | | | Summary: The PC corresponding to the breakpoint was being calculated wrongly, which was causing LLDB to never go past the first breakpoint, when there was a second one adjacent to it. Reviewers: clayborg, labath Reviewed By: clayborg, labath Subscribers: anajuliapc, alexandreyy, lbianc Differential Revision: https://reviews.llvm.org/D43344 Patch by Leandro Lupori <leandro.lupori@gmail.com>. llvm-svn: 325728
* Fix the cputype comparison in ↵Jason Molenda2018-02-051-1/+5
| | | | | | | | | GDBRemoteCommunicationServerCommon::Handle_qHostInfo to use Mach-O cpu types instead of the ArchSpec enum value, and handle the case of bridgeos. llvm-svn: 324287
* Fix a crash in *NetBSD::Factory::LaunchKamil Rytarowski2018-02-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We cannot call process_up->SetState() inside the NativeProcessNetBSD::Factory::Launch function because it triggers a NULL pointer deference. The generic code for launching a process in: GDBRemoteCommunicationServerLLGS::LaunchProcess sets the m_debugged_process_up pointer after a successful call to m_process_factory.Launch(). If we attempt to call process_up->SetState() inside a platform specific Launch function we end up dereferencing a NULL pointer in NativeProcessProtocol::GetCurrentThreadID(). Use the proper call process_up->SetState(,false) that sets notify_delegates to false. Sponsored by <The NetBSD Foundation> Reviewers: labath, joerg Reviewed By: labath Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D42868 llvm-svn: 324234
* Fix a copy of a fixed length, possibly non-nul terminated, stringJason Molenda2018-02-021-1/+1
| | | | | | | | | | | | into a std::string so we don't run off the end of the array when there is no nul byte in ProcessElfCore::parseLinuxNotes. Found with ASAN testing. <rdar://problem/37134319> Differential revision: https://reviews.llvm.org/D42828 llvm-svn: 324156
* Fix NetBsd build broken by r323637Pavel Labath2018-01-291-1/+1
| | | | llvm-svn: 323639
* Remove ObjectFile usage from HostLinux::GetProcessInfoPavel Labath2018-01-292-21/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The ObjectFile class was used to determine the architecture of a running process by inspecting it's main executable. There were two issues with this: - it's in the wrong layer - the call can be very expensive (it can end up computing the crc of the whole file). Since the process is running on the host, ideally we would be able to just query the data straight from the OS like darwin does, but there doesn't seem to be a reasonable way to do that. So, this fixes the layering issue by using the llvm object library to inspect the file. Since we know the process is already running on the host, we just need to peek at a few bytes of the elf header to determine whether it's 32- or 64-bit (which should make this faster as well). Pretty much the same logic was implemented in NativeProcessProtocol::ResolveProcessArchitecture, so I delete this logic and replace calls with GetProcessInfo. Reviewers: eugene, krytarowski Subscribers: mgorny, hintonda, lldb-commits Differential Revision: https://reviews.llvm.org/D42488 llvm-svn: 323637
* Prevent unaligned memory read in parseMinidumpStringRaphael Isemann2018-01-231-5/+10
| | | | | | | | | | | | | | | | | | | Summary: It's possible to hit an unaligned memory read when reading `source_length` as the `data` array is only aligned with 2 bytes (it's actually a UTF16 array). This patch memcpy's `source_length` into a local variable to prevent this: ``` MinidumpTypes.cpp:49:23: runtime error: load of misaligned address 0x7f0f4792692a for type 'const uint32_t' (aka 'const unsigned int'), which requires 4 byte alignment ``` Reviewers: dvlahovski, zturner, davide Reviewed By: davide Subscribers: davide, lldb-commits Differential Revision: https://reviews.llvm.org/D42348 llvm-svn: 323181
* Add SysV Abi for PPC64lePavel Labath2018-01-222-0/+470
| | | | | | | | | | | | | | | | | Summary: This patch implements the ABI Plugin for PPC64le. It was based on the ABI for PPC64. It also enables LLDB to evaluate expressions using JIT. Reviewers: labath, clayborg, jhibbits, davide Reviewed By: labath, clayborg, jhibbits, davide Subscribers: davide, JDevlieghere, chmeee, emaste, jhibbits, hfinkel, lldb-commits, nemanjai, luporl, lbianc, mgorny, anajuliapc, kbarton Differential Revision: https://reviews.llvm.org/D41702 Patch by Alexandre Yukio Yamashita <alexandre.yamashita@eldorado.org.br> llvm-svn: 323100
* One more attempt to fix NetBSD buildPavel Labath2018-01-151-1/+1
| | | | llvm-svn: 322477
* Fix NetBSD build for llvm r322475Pavel Labath2018-01-151-3/+3
| | | | llvm-svn: 322476
* When parsing the target.xml register file, if no architecture hasJason Molenda2018-01-121-0/+13
| | | | | | | | | | | | | | | | | been specified yet (either by the user, or by one of the lldb extensions like qHostInfo or qProcessInfo), and the target.xml includes a <architecture> tag specifying x86_64, set the architecture appropriately. I'm not sure what we can expect to see in the <architecture> tag, so I'm only doing this for x86_64 right now where I've seen "i386:x86_64" used. I've seen a target.xml from a jtag board that sends just "arm" because it doesn't know more specifically what type of board it is connected to... <rdar://problem/29908970> llvm-svn: 322339
* Handle O reply packets during qRcmdPavel Labath2018-01-105-3/+55
| | | | | | | | | | | | | | | | | | | | Summary: Gdb servers like openocd may send many $O reply packets for the client to output during a qRcmd command sequence. Currently, lldb interprets the first O packet as an unexpected response. Besides generating no output, this causes lldb to get out of sync with future commands because it continues reading O packets from the first command as response to subsequent commands. This patch handles any O packets during an qRcmd, treating the first non-O packet as the true response. Preliminary discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013078.html Reviewers: clayborg Reviewed By: clayborg Subscribers: labath, lldb-commits Differential Revision: https://reviews.llvm.org/D41745 Patch by Owen Shaw <llvm@owenpshaw.net> llvm-svn: 322190
* Another attempt to fix FreeBsd buildPavel Labath2018-01-103-18/+13
| | | | | | | | | | the previous fix did not work because of different const qualifications on the envp pointer. This should resolve that (and remove a couple of const_casts in the process). llvm-svn: 322187
* Fix windows and freebsd builds for r322174 (Environment)Pavel Labath2018-01-101-3/+2
| | | | llvm-svn: 322176
* Add Utility/Environment class for handling... environmentsPavel Labath2018-01-105-18/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There was some confusion in the code about how to represent process environment. Most of the code (ab)used the Args class for this purpose, but some of it used a more basic StringList class instead. In either case, the fact that the underlying abstraction did not provide primitive operations for the typical environment operations meant that even a simple operation like checking for an environment variable value was several lines of code. This patch adds a separate Environment class, which is essentialy a llvm::StringMap<std::string> in disguise. To standard StringMap functionality, it adds a couple of new functions, which are specific to the environment use case: - (most important) envp conversion for passing into execve() and likes. Instead of trying to maintain a constantly up-to-date envp view, it provides a function which creates a envp view on demand, with the expectation that this will be called as the very last thing before handing the value to the system function. - insert(StringRef KeyEqValue) - splits KeyEqValue into (key, value) pair and inserts it into the environment map. - compose(value_type KeyValue) - takes a map entry and converts in back into "KEY=VALUE" representation. With this interface most of the environment-manipulating code becomes one-liners. The only tricky part was maintaining compatibility in SBLaunchInfo, which expects that the environment entries are accessible by index and that the returned const char* is backed by the launch info object (random access into maps is hard and the map stores the entry in a deconstructed form, so we cannot just return a .c_str() value). To solve this, I have the SBLaunchInfo convert the environment into the "envp" form, and use it to answer the environment queries. Extra code is added to make sure the envp version is always in sync. (This also improves the layering situation as Args was in the Interpreter module whereas Environment is in Utility.) Reviewers: zturner, davide, jingham, clayborg Subscribers: emaste, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D41359 llvm-svn: 322174
* [MacOSX-Kernel] Remove broken KDP_IMAGEPATH support.Davide Italiano2018-01-021-37/+0
| | | | llvm-svn: 321652
* Fix a couple of warnings (NFC)Adrian Prantl2017-12-192-1/+2
| | | | llvm-svn: 321120
* Fix regression in jModulesInfo packet handlingPavel Labath2017-12-181-1/+3
| | | | | | | | | | | | | | | | | | | | | | | 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
* llgs: Propagate the environment when launching the inferior from command linePavel Labath2017-12-182-41/+3
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix FreeBSD build broken by r320966Pavel Labath2017-12-181-25/+22
| | | | llvm-svn: 320969
* Reduce x86 register context boilerplate.Pavel Labath2017-12-185-82/+71
| | | | | | | | | | | | | | | | | | | | | | 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
* NPL: Clean up handling of inferior exitPavel Labath2017-12-182-47/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove stderr message from GDBRemoteCommunicationServerLLGSPavel Labath2017-12-141-7/+2
| | | | | | | | 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
* Avoid module import in a textual header, NFCVedant Kumar2017-12-121-5/+2
| | | | | | This unbreaks the lldb modules build (-DLLVM_ENABLE_MODULES=On). llvm-svn: 320456
* Move PseudoTerminal to the lldb_private namespacePavel Labath2017-12-113-5/+4
| | | | | | | lldb_utility doesn't make sense, as it is no longer even living in the "utility" module. llvm-svn: 320346
* [MachException] Garbage collect unused and dead code.Davide Italiano2017-12-101-27/+0
| | | | llvm-svn: 320337
* Remove extant references to g_message_mutex, NFCVedant Kumar2017-12-081-8/+0
| | | | | | Thanks to Jim Ingham for providing the explanation! llvm-svn: 320126
* Fix const-correctness in RegisterContext methods, NFCVedant Kumar2017-12-063-10/+30
| | | | | | | | | | 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
* Remove no-op function pointer null checks, NFCVedant Kumar2017-12-062-20/+7
| | | | | | | | | | | | | | 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
* [Darwin] Delete dead code. NFCI.Davide Italiano2017-12-051-28/+0
| | | | llvm-svn: 319832
* Kill struct IOVECPavel Labath2017-12-019-24/+10
| | | | | | | | | | | 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
* elf-core: Convert remaining register context to use register set mapsPavel Labath2017-11-2823-195/+226
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In https://reviews.llvm.org/D39681, we started using a map instead passing a long list of register sets to the ppc64le register context. However, existing register contexts were still using the old method. This converts the remaining register contexts to use this approach. While doing that, I've had to modify the approach a bit: - the general purpose register set is still kept as a separate field, because this one is always present, and it's parsing is somewhat different than that of other register sets. - since the same register sets have different IDs on different operating systems, but we use the same register context class to represent different register sets, I've needed to add a layer of indirection to translate os-specific constants (e.g. NETBSD::NT_AMD64_FPREGS) into more generic terms (e.g. floating point register set). While slightly more complicated, this setup allows for better separation of concerns. The parsing code in ProcessElfCore can focus on parsing OS-specific core file notes, and can completely ignore architecture-specific register sets (by just storing any unrecognised notes in a map). These notes will then be passed on to the architecture-specific register context, which can just deal with architecture specifics, because the OS-specific note types are hidden in a register set description map. This way, adding an register set, which is already supported on other OSes, to a new OS, should in most cases be as simple as adding a new entry into the register set description map. Differential Revision: https://reviews.llvm.org/D40133 llvm-svn: 319162
* Fix floating point register write on new x86 linux kernelsPavel Labath2017-11-284-5/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: New linux kernels (on systems that support the XSAVES instruction) will not update the inferior registers unless the corresponding flag in the XSAVE header is set. Normally this flag will be set in our image of the XSAVE area (since we obtained it from the kernel), but if the inferior has never used the corresponding register set, the respective flag can be clear. This fixes the issue by making sure we explicitly set the flags corresponding to the registers we modify. I don't try to precisely match the flags to set on each write, as the rules could get quite complicated -- I use a simpler over-approximation instead. This was already caught by test_fp_register_write, but that was only because the code that ran before main() did not use some of the register sets. Since nothing in this test relies on being stopped in main(), I modify the test to stop at the entry point instead, so we can be sure the inferior did not have a chance to access these registers. Reviewers: clayborg, valentinagiusti Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D40434 llvm-svn: 319161
* elf-core: Split up parsing code into os-specific functionsPavel Labath2017-11-235-226/+311
| | | | | | | | | | | | | | | | | | Summary: We've had a single function responsible for splitting a core segment into notes, and parsing the notes themselves, bearing in mind variations between 4 supported OS types. This commit splits that code into 5 pieces: - (os-independent) code for splitting a segment into individual notes - per-os function for parsing the notes into thread information Reviewers: clayborg, krytarowski, emaste, alexandreyy, kettenis Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D40311 llvm-svn: 318903
* Remove unused variable.Tatyana Krasnukha2017-11-221-1/+1
| | | | llvm-svn: 318833
* Implement core dump debugging for PPC64lePavel Labath2017-11-1611-54/+589
| | | | | | | | | | | | | | | Summary: Implement core dump debugging for PPC64le. Reviewers: labath Reviewed By: labath Subscribers: JDevlieghere, krytarowski, clayborg, labath, lbianc, nemanjai, gut, anajuliapc, mgorny, kbarton, lldb-commits Differential Revision: https://reviews.llvm.org/D39681 Patch by Alexandre Yukio Yamashita <alexandre.yamashita@eldorado.org.br> llvm-svn: 318399
* Fix alignment of arm64 fpu register context structureJason Molenda2017-11-162-3/+3
| | | | | | | | | | so it has the same padding as the kernel's definition which is written in terms of uint128_t. Original patch by Ryan Mansfield. <rdar://problem/35468499> llvm-svn: 318357
* Roll back r318260 because it is causing the windows bot toJason Molenda2017-11-151-1/+1
| | | | | | | | | | break. The alignas(__uint128_t) is not recognized with MSVC it looks like. Zachary, is there a similar type on windows? I suppose I can go with alignas(16) here but I'd prefer to specify the type alignment that I want & let the ABI dictate how much padding is required. llvm-svn: 318262
* Two small fixes to handle arm64 fpu register contexts in Jason Molenda2017-11-151-1/+1
| | | | | | | | | a Mach-O file load command correctly, patch by Ryan Mansfield. <rdar://problem/35468499> llvm-svn: 318260
* Fix netbsd, freebsd and osx builds for ArchSpec movePavel Labath2017-11-136-10/+6
| | | | llvm-svn: 318052
* Move ArchSpec to the Utility modulePavel Labath2017-11-1310-26/+8
| | | | | | | | | | | | | The rationale here is that ArchSpec is used throughout the codebase, including in places which should not depend on the rest of the code in the Core module. This commit touches many files, but most of it is just renaming of #include lines. In a couple of cases, I removed the #include ArchSpec line altogether, as the file was not using it. In one or two places, this necessitated adding other #includes like lldb-private-defines.h. llvm-svn: 318048
* Clean up NativeRegisterContextPavel Labath2017-11-1027-299/+200
| | | | | | | | | | | | | | | | | | | | | Summary: This commit removes the concrete_frame_idx member from NativeRegisterContext and related functions, which was always set to zero and never used. I also change the native thread class to store a NativeRegisterContext as a unique_ptr (documenting the ownership) and make sure it is always initialized (most of the code was already blindly dereferencing the register context pointer, assuming it would always be present -- this makes its treatment consistent). Reviewers: eugene, clayborg, krytarowski Subscribers: aemerson, sdardis, nemanjai, javed.absar, arichardson, kristof.beyls, kbarton, uweigand, alexandreyy, lldb-commits Differential Revision: https://reviews.llvm.org/D39837 llvm-svn: 317881
* llgs-tests: Replace the "log+return false" pattern with llvm::ErrorPavel Labath2017-11-092-0/+46
| | | | | | | | | | | | | | | | | | | | Summary: These tests used to log the error message and return plain bool mainly because at the time they we written, we did not have a nice way to assert on llvm::Error values. That is no longer true, so replace this pattern with a more idiomatic approach. As a part of this patch, I also move the formatting of GDBRemoteCommunication::PacketResult values out of the test code, as that can be useful elsewhere. Reviewers: zturner, eugene Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D39790 llvm-svn: 317795
* Simplify NativeProcessProtocol::GetArchitecture/GetByteOrderPavel Labath2017-11-0910-62/+17
| | | | | | | | | | | | | | | | | | | Summary: These functions used to return bool to signify whether they were able to retrieve the data. This is redundant because the ArchSpec and ByteOrder already have their own "invalid" states, *and* because both of the current implementations (linux, netbsd) can always provide a valid result. This allows us to simplify bits of the code handling these values. Reviewers: eugene, krytarowski Subscribers: javed.absar, lldb-commits Differential Revision: https://reviews.llvm.org/D39733 llvm-svn: 317779
* Improve the posix core file triple detectionTamas Berghammer2017-11-041-5/+8
| | | | | | | | | | | | | | | | | | | | | | | Summary: Posix core files sometime don't contain enough information to correctly detect the OS. If that is the case we should use the OS from the target instead as it will contain usable information in more cases and if the target and the core contain different OS-es then we are already in a pretty bad state so moving from an unknown OS to a known (but possibly incorrect) OS will do no harm. We already had similar code in place for MIPS. This change tries to make it more generic by using ArchSpec::MergeFrom and extends it to all architectures but some MIPS specific issue prevent us from getting rid of special casing MIPS. Reviewers: clayborg, nitesh.jain Subscribers: aemerson, sdardis, arichardson, kristof.beyls, lldb-commits Differential Revision: https://reviews.llvm.org/D36046 llvm-svn: 317411
* Remove ProcessGdbRemote::m_flagsPavel Labath2017-11-032-7/+1
| | | | | | The member is completely unused. Discussed on lldb-dev. llvm-svn: 317377
* Add float/vector registers for ppc64lePavel Labath2017-11-034-17/+832
| | | | | | | | | | | | | | | Summary: Add read and write functions for VSX, VMX and float registers and fix watchpoint size Reviewers: clayborg Reviewed By: clayborg Subscribers: eugene, labath, clayborg, nemanjai, kbarton, JDevlieghere, anajuliapc, gut, lbianc, lldb-commits Differential Revision: https://reviews.llvm.org/D39487 Patch by: Alexandre Yukio Yamashita <alexandre.yamashita@eldorado.org.br> llvm-svn: 317329
OpenPOWER on IntegriCloud