summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove more dead code from NativeProcessLinuxAlex Langford2018-06-081-14/+0
| | | | | | This should have been removed in r334333. llvm-svn: 334336
* Delete dead code in NativeProcessLinuxAlex Langford2018-06-081-149/+0
| | | | | | | As far as I can tell, this code has always been guarded by `#if 0`. If this is useful code, it can be added back. llvm-svn: 334333
* Fix DynamicRegisterInfo copying/moving issue.Tatyana Krasnukha2018-06-082-23/+51
| | | | | | | | | | | | | | | Summary: Default copy/move constructors and assignment operators leave wrong m_sets[i].registers pointers. Made the class movable and non-copyable (it's difficult to imagine when it needs to be copied). Reviewers: clayborg Reviewed By: clayborg Differential Revision: https://reviews.llvm.org/D47728 llvm-svn: 334282
* [lldb, process] Fix occasional hang when launching a process in LLDBStella Stamenova2018-06-011-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Occasionally, when launching a process in lldb (especially on windows, but not limited to), lldb will hang before the process is launched and it will never recover. This happens because the timing of the processing of the state changes can be slightly different. The state changes that are issued are: 1) SetPublicState(eStateLaunching) 2) SetPrivateState(eStateLaunching) 3) SetPublicState(eStateStopped) 4) SetPrivateState(eStateStopped) What we expect to see is: public state: launching -> launching -> stopped private state: launching -> stopped What we see is: public state: launching -> stopped -> launching private state: launching -> stopped The second launching change to the public state is issued when WaitForProcessStopPrivate calls HandlePrivateEvent on the event which was created when the private state was set to launching. HandlePrivateEvent has logic to determine whether to broadcase the event and a launching event is *always* broadcast. At the same time, when the stopped event is processed by WaitForProcessStopPrivate next, the function exists and that event is never broadcast, so the public state remains as launching. HandlePrivateEvent does two things: determine whether there's a next action as well as determine whether to broadcast the event that was processed. There's only ever a next action set if we are trying to attach to a process, but WaitForProcessStopPrivate is only ever called when we are launching a process or connecting remotely, so the first part of HandlePrivateEvent (handling the next action) is irrelevant for WaitForProcessStopPrivate. As far as broadcasting the event is concerned, since we are handling state changes that already occurred to the public state (and are now duplicated in the private state), I believe the broadcast step is unnecessary also (and in fact, it causes the hang). This change removes the call to HandlePrivateEvent from inside WaitForProcessStopPrivate. Incidentally, there was also a bug filed recently that is the same issue: https://bugs.llvm.org/show_bug.cgi?id=37496 Reviewers: asmith, labath, zturner, jingham Reviewed By: zturner, jingham Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D47609 llvm-svn: 333781
* Typo fixes.Bruce Mitchener2018-05-296-15/+15
| | | | | | | | | | Reviewers: javed.absar Subscribers: ki.stfu, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D47421 llvm-svn: 333399
* Add missing includes to some LLDB headers.Raphael Isemann2018-05-262-0/+4
| | | | | | | | | | Summary: When compiling with modules, these missing includes cause the build to fail (as the header can't be compiled into a module). Subscribers: ki.stfu, lldb-commits Differential Revision: https://reviews.llvm.org/D47412 llvm-svn: 333345
* Remove spurious dependency on Process/elf-core from Process/Utility.James Y Knight2018-05-236-31/+6
| | | | | | | These checks do absolutely nothing other than cause a library layering violation in the code. llvm-svn: 333134
* Normalize some lldb #include statements.James Y Knight2018-05-2217-36/+10
| | | | | | | | | | | Most non-local includes of header files living under lldb/sources/ were specified with the full path starting after sources/. However, in a few instances, other sub-directories were added to include paths, or Normalize those few instances to follow the style used by the rest of the codebase, to make it easier to understand. llvm-svn: 333035
* Enable ProcessMachCore plugin on non-apple platformsPavel Labath2018-05-221-1/+1
| | | | | | | | | | | | | | | | | | | Summary: The plugin already builds fine on other platforms (linux, at least). All that was necessary was to revitalize the hack in PlatformDarwinKernel (not a very pretty hack, but it gets us going at least). I haven't done a thorough investigation of the state of the plugin on other platforms, but at least the two core file tests we have seem to pass, so I enable them. Reviewers: JDevlieghere, jasonmolenda Subscribers: lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D47133 llvm-svn: 332997
* [lldb] Fix compile warnings in r332702Eric Liu2018-05-182-4/+5
| | | | | | | | | | | | | | | | Summary: - Fix #include path - Fix warning: ```` error: format specifies type 'unsigned long long' but the argument has type 'uint64_t' (aka 'unsigned long') [-Werror,-Wformat] ``` Reviewers: labath, javed.absar Differential Revision: https://reviews.llvm.org/D47072 llvm-svn: 332733
* Add back #ifdef __APPLE__ to ↵Pavel Labath2018-05-182-3/+3
| | | | | | | | | | | RegisterContextDarwin_xxx::NumSupportedHardwareWatchpoints It turns out these class still contained some os-specific functionality, but I did not notice that originally, as it was #ifdef arm(64). This adds back the __APPLE__ condition to these particular functions, unbreaking arm builds on other OSs. llvm-svn: 332710
* Make ObjectFileMachO work on non-darwin platformsPavel Labath2018-05-183-17/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this patch we were unable to write cross-platform MachO tests because the parsing code did not compile on other platforms. The reason for that was that ObjectFileMachO depended on RegisterContextDarwin_arm(64)? (presumably for core file parsing) and the two Register Context classes uses constants from the system headers (KERN_SUCCESS, KERN_INVALID_ARGUMENT). As far as I can tell, these two files don't actually interact with the darwin kernel -- they are used only in ObjectFileMachO and MacOSX-Kernel process plugin (even though it has "kernel" in the name, this one communicates with it via network packets and not syscalls). For the time being I have created OS-independent definitions of these constants and made the register context classes use those. Long term, the error handling in these classes should be probably changed to use more standard mechanisms such as Status or Error classes. This is the only change necessary (apart from build system glue) to make ObjectFileMachO work on other platforms. To demonstrate that, I remove REQUIRES:darwin from our (only) cross-platform mach-o test. Reviewers: jasonmolenda, aprantl, clayborg, javed.absar Subscribers: mgorny, lldb-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D46934 llvm-svn: 332702
* [Windows, Process] LLDB reads wrong registers on 64bit WindowsStella Stamenova2018-05-171-16/+16
| | | | | | | | | | | | | | | | | | Summary: LLDB reads wrong registers on 64bit Windows because RegisterContextWindows_x64::GetRegisterInfoAtIndex returns wrong reference. I encountered broken backtrace when the program stopped at function which does not have prologue code, such as compiled with '-fomit-frame-pointer'. In this situation, CFA is equal to rsp but LLDB reads r9. RegisterContextWindows_x64::GetRegisterInfoAtIndex depends the order of lldb_XXX_x86_64 values, but RegisterIndex/g_register_infos/g_gpr_reg_indices does not follow order. In source/Plugins/Process/Utility/lldb-x86-register-enums.h The order of GPRs is rax, rbx, rcx, rdx, rdi, rsi, rbp, rsp, r8, ... In source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp The order of GPRs is rax, rbx, rcx, rdx, rdi, rsi, r8, r9, r10, ... Patch by Kenji Koyanagi llvm-svn: 332671
* [Windows, Process] Fix an issue in windows thread handling that was causing ↵Stella Stamenova2018-05-173-7/+25
| | | | | | | | | | | | | | | | LLDB to hang Summary: The function ResumeThread on Windows returns a DWORD which is an unsigned int. In TargetThreadWindows::DoResume, there's code that determines how many times to call ResumeThread based on whether the return value is greater than 0. Since the function returns -1 (as an unsigned int) on failure, this was getting stuck in an infinite loop if ResumeThread failed for any reason. The correct thing to do is check whether the return value is -1 and then return the appropriate error instead of ignoring the return value. Reviewers: asmith, zturner, labath Reviewed By: zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D47020 llvm-svn: 332670
* Convert all RunShellCommand functions to use the Timeout classPavel Labath2018-05-103-9/+10
| | | | | | | this completes the Timeout migration started in r331880 with the Predicate class. llvm-svn: 331970
* Fix Windows build for the Predicate.h refactor in r331880Pavel Labath2018-05-091-2/+2
| | | | llvm-svn: 331882
* Modernize and clean-up the Predicate classPavel Labath2018-05-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The comments on this class were out of date with the implementation, and the implementation itself was inconsistent with our usage of the Timeout class (I started converting everything to use this class back in D27136, but I missed this one). I avoid duplicating the waiting logic by introducing a templated WaitFor function, and make other functions delegate to that. This function can be also used as a replacement for the unused WaitForBitToBeSet functions I removed, if it turns out to be necessary. As this changes the meaning of a "zero" timeout, I tracked down all the callers of these functions and updated them accordingly. Propagating the changes to all the callers of RunShellCommand was a bit too much for this patch, so I stopped there and will continue that in a follow-up patch. I also add some basic unittests for the functions I modified. Reviewers: jingham, clayborg Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D46580 llvm-svn: 331880
* Remove the timed_out out-argument from Predicate::WaitForValueEqualToPavel Labath2018-05-031-1/+1
| | | | | | | | | The function can only return in one of two ways: the Predicate value is successfully set within the allotted time, or it isn't (the wait times out). These states can be represented in the return value, and the extra arg adds no value. llvm-svn: 331458
* Use the UUID from the minidump's CodeView Record for placeholder modulesLeonard Mosescu2018-05-024-4/+60
| | | | | | | | | | | | | | | This change adds support for two types of Minidump CodeView records: PDB70 (reference: https://crashpad.chromium.org/doxygen/structcrashpad_1_1CodeViewRecordPDB70.html) This is by far the most common record type. ELF BuildID (found in Breakpad/Crashpad generated minidumps) This would set a proper UUID for placeholder modules, in turn enabling an accurate match with local module images. Differential Revision: https://reviews.llvm.org/D46292 llvm-svn: 331394
* Enable AUTOBRIEF in doxygen configuration.Adrian Prantl2018-05-0210-64/+63
| | | | | | | | | | | | | | This brings the LLDB configuration closer to LLVM's and removes visual clutter in the source code by removing the @brief commands from comments. This patch also reflows the paragraphs in all doxygen comments. See also https://reviews.llvm.org/D46290. Differential Revision: https://reviews.llvm.org/D46321 llvm-svn: 331373
* Reflow paragraphs in comments.Adrian Prantl2018-04-3067-1863/+1528
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
* FreeBSD: propagate error to user if memory access failsEd Maste2018-04-211-2/+6
| | | | | | | | | | Previously, an attempt to read an unreadable address reported zeros. Now, if DoReadMemory or DoWriteMemory encounters error then return 0 (bytes read or written) so that the error is reported to the user. llvm.org/pr37190 llvm-svn: 330500
* Attempt to fix TestMiniDump on windowsPavel Labath2018-04-191-1/+2
| | | | | | | | | | | | | | | | | | | | | | | It was failing because the modules names were coming out as C:\Windows\System32/MSVCP120D.dll (last separator is a forward slash) on windows. There are two issues at play here: - the first problem is that the paths in minidump were being parsed as a host path. This meant that on posix systems the whole path was interpreted as a file name. - on windows the path was split into a directory-filename pair correctly, but then when it was reconsituted, the last separator ended up being a forward slash because SBFileSpec.fullpath was joining them with '/' unconditionally. I fix the first issue by parsing the minidump paths according to the path syntax of the host which produced the dump, which should make the test behavior on posix&windows identical. The last path will still be a forward slash because of the second issue. We should probably fix the "fullpath" property to do something smarter in the future. llvm-svn: 330314
* Improve LLDB's handling of non-local minidumpsLeonard Mosescu2018-04-182-1/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Normally, LLDB is creating a high-fidelity representation of a live process, including a list of modules and sections, with the associated memory address ranges. In order to build the module and section map LLDB tries to locate the local module image (object file) and will parse it. This does not work for postmortem debugging scenarios where the crash dump (minidump in this case) was captured on a different machine. Fortunately the minidump format encodes enough information about each module's memory range to allow us to create placeholder modules. This enables most LLDB functionality involving address-to-module translations. Also, we may want to completly disable the search for matching local object files if we load minidumps unless we can prove that the local image matches the one from the crash origin. (not part of this change, see: llvm.org/pr35193) Example: Identify the module from a stack frame PC: Before: thread #1, stop reason = Exception 0xc0000005 encountered at address 0x164d14 frame #0: 0x00164d14 frame #1: 0x00167c79 frame #2: 0x00167e6d frame #3: 0x7510336a frame #4: 0x77759882 frame #5: 0x77759855 After: thread #1, stop reason = Exception 0xc0000005 encountered at address 0x164d14 frame #0: 0x00164d14 C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe frame #1: 0x00167c79 C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe frame #2: 0x00167e6d C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe frame #3: 0x7510336a C:\Windows\SysWOW64\kernel32.dll frame #4: 0x77759882 C:\Windows\SysWOW64\ntdll.dll frame #5: 0x77759855 C:\Windows\SysWOW64\ntdll.dll Example: target modules list Before: error: the target has no associated executable images After: [ 0] C:\Windows\System32\MSVCP120D.dll [ 1] C:\Windows\SysWOW64\kernel32.dll [ 2] C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe [ 3] C:\Windows\System32\MSVCR120D.dll [ 4] C:\Windows\SysWOW64\KERNELBASE.dll [ 5] C:\Windows\SysWOW64\ntdll.dll NOTE: the minidump format also includes the debug info GUID, so we can fill-in the module UUID from it, but this part was excluded from this change to keep the changes simple (the LLDB UUID is hardcoded to be either 16 or 20 bytes, while the CodeView GUIDs are normally 24 bytes) Differential Revision: https://reviews.llvm.org/D45700 llvm-svn: 330302
* Report more precise error message when attach failsPavel Labath2018-04-181-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: If the remote stub sends a specific error message instead of just a E?? code, we can use this to display a more informative error message instead of just the generic "unable to attach" message. I write a test for this using the SB API. On the console this will show up like: (lldb) process attach ... error: attach failed: <STUB-MESSAGE> if the stub supports error messages, or: error: attach failed: Error ?? if it doesn't. Reviewers: jingham, JDevlieghere Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D45573 llvm-svn: 330247
* Move Args.cpp from Interpreter to UtilityPavel Labath2018-04-174-4/+4
| | | | | | | | | | | | | | | | | | | | | Summary: The Args class is used in plenty of places besides the command interpreter (e.g., anything requiring an argc+argv combo, such as when launching a process), so it needs to be in a lower layer. Now that the class has no external dependencies, it can be moved down to the Utility module. This removes the last (direct) dependency from the Host module to Interpreter, so I remove the Interpreter module from Host's dependency list. Reviewers: zturner, jingham, davide Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D45480 llvm-svn: 330200
* Re-land "Don't assume backing thread shares protocol ID."Jonas Devlieghere2018-04-131-4/+3
| | | | | | | | | | | | | | | | | | When we're dealing with virtual (memory) threads created by the OS plugins, there's no guarantee that the real thread and the backing thread share a protocol ID. Instead, we should iterate over the memory threads to find the virtual thread that is backed by the current real thread. Differential revision: https://reviews.llvm.org/D45497 rdar://36485830 The original revision (r329891) was reverted because the associated tests ran into a deadlock on the Linux bots. That problem was resolved by r330002. llvm-svn: 330005
* Revert "Don't assume backing thread shares protocol ID."Jonas Devlieghere2018-04-121-3/+4
| | | | | | | This reverts r329891 because the test case is timing out on linux: http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/21834 llvm-svn: 329897
* Don't assume backing thread shares protocol ID.Jonas Devlieghere2018-04-121-4/+3
| | | | | | | | | | | | | | When we're dealing with virtual (memory) threads created by the OS plugins, there's no guarantee that the real thread and the backing thread share a protocol ID. Instead, we should iterate over the memory threads to find the virtual thread that is backed by the current real thread. Differential revision: https://reviews.llvm.org/D45497 rdar://36485830 llvm-svn: 329891
* llgs: Send "rich" errors in response to vAttach packetsPavel Labath2018-04-112-4/+4
| | | | | | | | | | | | | | | | | There are plenty of ways attaching can go wrong. Having the server report the exact error means we can give better feedback to the user. (This patch does not do the second part, it only makes sure the information is sent from the server.) Triggering all possible error conditions in a test would prove challenging, but there is one error that is very easy to reproduce (attempting to attach while debugging), so I write a test based on that. The test immediately exposed a bug where the m_send_error_strings field was being used uninitialized (so it was sometimes true from the get-go), so I fix that as well. llvm-svn: 329803
* Move Args::StringTo*** functions to a new OptionArgParser classPavel Labath2018-04-103-5/+8
| | | | | | | | | | | | | | | | Summary: The idea behind this is to move the functionality which depend on other lldb classes into a separate class. This way, the Args class can be turned into a lightweight arc+argv wrapper and moved into the lower lldb layers. Reviewers: jingham, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D44306 llvm-svn: 329677
* Fix windows build after r329296Pavel Labath2018-04-052-0/+2
| | | | | | Add a couple of #include <csignal>s. llvm-svn: 329309
* Prevent double release of mach portsFrederic Riss2018-03-291-2/+0
| | | | | | | | | | | | | | | | Summary: When a MIG routine returns KERN_FAILURE, the demux function will release any OOL resources like ports. In this case, task_port and thread_port will be released twice, potentially resulting in use after free of the ports. I don't think we can test this in any useful way rdar://problem/37331387 Reviewers: jasonmolenda Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D45011 llvm-svn: 328761
* gdb-remote: Fix checksum verification for messages with escape charsPavel Labath2018-03-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We've had a mismatch in the checksum computation between the sender and receiver. The sender computed the payload checksum using the wire encoding of the packet, while the receiver did this after expanding un-escaping and expanding run-length-encoded sequences. This resulted in communication breakdown if packets using these feature were sent in the ack mode. Normally, this did not cause any issues since the only packet we send in the ack-mode is the QStartNoAckMode packet, but I ran into this when debugging the lldb-server tests which (for better or worse) don't use this mode. According to the gdb-remote documentation "The two-digit checksum is computed as the modulo 256 sum of all characters between the leading ‘$’ and the trailing ‘#’", it seems that our sender is doing the right thing here. Therefore, I fix the receiver the match the sender behavior and add a test. With this bug fixed, we can see that lldb-server is sending a stop-reply after receiving the "k" in the same way as debugserver does (but we weren't detecting this because at that point the connection was dead already). I fix that expectation as well. Reviewers: clayborg, jasonmolenda Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D44922 llvm-svn: 328693
* Move StringExtractorGDBRemote.h to the include folderPavel Labath2018-03-2010-10/+10
| | | | | | | | While trying to use this header I noticed that it is not in the include folder. Move it to there and update all #includes to reference that file correctly. llvm-svn: 327996
* Re-land: [lldb] Use vFlash commands when writing to target's flash memory ↵Pavel Labath2018-03-204-9/+339
| | | | | | | | | | | | | | | | | | | | | | | | | | | | regions The difference between this and the previous patch is that now we use ELF physical addresses only for loading objects into the target (and the rest of the module load address logic still uses virtual addresses). 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: llvm-commits, arichardson, emaste, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D42145 Patch by Owen Shaw <llvm@owenpshaw.net>. llvm-svn: 327970
* Use GetItemAtIndexAsString overload for ConstString and move set rather than ↵Tatyana Krasnukha2018-03-141-6/+3
| | | | | | copy. llvm-svn: 327549
* Fix linux s390x build (pr36694)Pavel Labath2018-03-131-1/+1
| | | | llvm-svn: 327379
* [LLDB][PPC64] Fixed issues with expedited registersPavel Labath2018-03-061-0/+4
| | | | | | | | | | | | | | | | | Summary: - reg_nums were missing the end marker entry - marked FP test to be skipped for ppc64 Reviewers: labath, clayborg Reviewed By: labath, clayborg Subscribers: alexandreyy, lbianc, nemanjai, kbarton Differential Revision: https://reviews.llvm.org/D43767 Patch by Leandro Lupori <leandro.lupori@gmail.com> llvm-svn: 326775
* Make Finalize tolerant of empty register sets.Tatyana Krasnukha2018-03-011-1/+1
| | | | llvm-svn: 326437
* 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
OpenPOWER on IntegriCloud